Репозитории в CentOS
Для начала давайте поясним, что такое репозитории и для чего они нужны. Вот что говорит wikipedia на этот счет:
Некоторое время назад Linux приложения выходили в виде исходного кода, который потом компилировали на сервере и получали готовые программы. На сегодняшний день большинство приложений выходят в виде так называемых пакетов. Это уже собранные приложения, которые можно сразу установить и пользоваться.
В нашем случае репозиторий — хранилище пакетов для операционной системы CentOS. Существуют repository от разработчика системы, их называют официальные. Набор rpm пакетов там обычно ограничен и версии не самые свежие. Для установки дополнительного софта используют сторонние репозитории. Их поддерживать могут как другие компании, так и группы энтузиастов.
Управлением пакетами и репозиториями в CentOS занимается утилита yum. Ее конфигурационный файл находится в /etc/yum.conf. Этот файл содержит секцию , в которой указываются глобальные настройки программы. Так же он может содержать одну или несколько секций , в которой хранятся настройки репозиториев. Тем не менее, рекомендуется информацию о репозиториях хранить в каталоге /etc/yum.repos.d/ в специальных файлах .repo.
Минимальное содержание файла .repo следующее:
| name | имя, описывающее репозиторий, может быть любым |
| baseurl | ссылка на расположение репозитория, может быть в виде http, ftp или file ссылки |
Другие ползные параметры, которые могут быть указаны в repo файле:
| enabled | принимает значение 1 или 0, 1 — репозиторий подключен, 0 — отключен |
| async | управляет загрузкой пакетов, auto — использует при возможности параллельную загрузку, on — использует только параллельную загрузку, off — параллельная загрузка отключена |
| mirrorlist | вместо ссылки на конкретный адрес репозитория может быть указана ссылка на список адресов, из которых при установке будет выбран наиболее подходящий |
| gpgcheck | принимает значение 1 или 0, 1- осуществлять проверку GPG подписи пакета из репозитория, 0 — не проверять |
| gpgkey | ссылка на GPG ключ репозитория |
Вот содержание стандартного файла с репозиториями CentOS /etc/yum.repos.d/CentOS-Base.repo:
Просмотр информации о пакетах
1. Список установленных пакетов:
yum list —installed
2. Получение зависимостей для пакета:
yum deplist <имя пакета>
Например:
yum deplist nginx
* покажет, какие пакеты или библиотеки необходимы для установки nginx. Дополнительно, могут быть указаны пакеты, которые нужны для удовлетворения зависимостей.
3. Посмотреть список файлов внутри установочного пакета.
Мы можем посмотреть данный список для уже установленного пакета:
rpm -ql <имя установленного пакета>
Например:
rpm -ql nginx
Или из установочного файла:
rpm -qlp <путь до RPM-пакета>
Например:
rpm -qlp nginx.rpm
4. Посмотреть, какой пакет предоставляет определенный файл:
yum provides audit-libs-python
В данном примере мы получим ответ:
audit-libs-python-2.8.5-4.el7.x86_64 : Python bindings for libaudit
Repo : base
Это значит, что audit-libs-python содержится в пакете audit-libs-python-2.8.5-4.el7.x86_64, который в свою очередь, находится в репозитории base.
Можно также выполнять поиск по маске:
yum provides audit-libs-*
Yandex mirror для CentOS
mirror.yandex.ru — сайт компании Яндекс, зеркало репозитариев популярных дистрибутивов Linux, FreeBSD и других проектов, в том числе CentOS. Работает по протоколам HTTP, FTP и rsync.
На зеркале CentOS можно скачать дистрибутивы всех актуальных на текущий момент версий, а это версии 5, 6 и 7. Зеркало можно использовать в качестве источников стандартных репозиториев системы — base, updates, extras, centosplus.
Можно использовать, что я неоднократно делал, yandex mirror для сетевой установки CentOS. Путь к установочному образу: http://mirror.yandex.ru/centos/7/os/x86_64/images/
На этом у меня все по теме работы с репозиториями.
Возможные ошибки
Рассмотрим примеры ошибок, с которыми мы можем столкнуться и способы их решения.
1. Curl error (60): SSL peer certificate or SSH remote key was not OK
Ошибка появляется при попытке выполнить операцию обновления или установки пакетов.
Причина: сертификат подключенного репозитория не проходит проверку. Возможно, он просрочен или выдан не доверенным центром сертификации.
Решение: проблему можно решить на стороне сервера (если мы являемся его администратором), например, получив правильный сертификат у Let’s Encrypt. На стороне клиента можно отключить проверку SSL для репозитория командой:
yum-config-manager —save —setopt=<имя репозитория>.sslverify=0
Или в конфигурационном файле репозитория добавить или изменить строку с sslverify:
sslverify=0
* данная опция задает необходимость проверки SSL для репозитория.
2. Error: GPG validation FAILED
Ошибка появляется при попытке установить пакет.
Причина: система не может загрузить и импортировать gpg-ключ. Это возможно в разных сценариях, например, в настройках репозитория не указан путь до него, но при этом указано, что проверка подписи необходима или ключ не удалось загрузить и импортировать.
Решение: для некоторых пакетов идет отдельная инструкция по настройке репозитория, в частности, установки ключа GPG. Или мы можем отключить проверку gpg командой:
yum-config-manager —save —setopt=<имя репозитория>.gpgcheck=0
Или через конфигурационный файл:
gpgcheck=0
Разные релизы CentOS
В одном репозитории мы можем легко хранить пакеты для различных релизов операционной системы CentOS (и не только CentOS, но и PPA). Для этого создаем каталог под новый релиз, синхронизируем его с источником и создаем из него репозиторий, например:
mkdir -p /usr/share/nginx/html/repos/6/{os,updates}/x86_64
* в данном примере предполагается использование репозитория для релиза 6.
Синхронизируем пакеты:
rsync -iavrt —delete —exclude=’repo*’ rsync://mirror.yandex.ru/centos/6/os/x86_64/ /usr/share/nginx/html/repos/6/os/x86_64/
rsync -iavrt —delete —exclude=’repo*’ rsync://mirror.yandex.ru/centos/6/updates/x86_64/ /usr/share/nginx/html/repos/6/updates/x86_64/
Создаем репозитории:
createrepo -v /usr/share/nginx/html/repos/6/os/x86_64
createrepo -v /usr/share/nginx/html/repos/6/updates/x86_64
Ошибка pacman «The requested URL returned error: 404»
Для работы менеджера пакетов имеется кэш — в этом кэше собрана информация о существующих пакетах для установки, их версиях и ссылки на скачивание. Чтобы обновить (или скачать впервые) этот кэш, нужно выполнить команду:
sudo pacman -Sy
После этого можно выполнять обновление системы или обновление пакета.
Если кэш устарел и вы пытаетесь установить пакет, версия которого обновилась и для которого в вашем локальном кэше старая ссылка, вы можете получить примерно следующую ошибку:
error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirrors.evowise.com : The requested URL returned error: 404
Для её исправления нужно выполнить приведённую выше команду, а затем повторить установку.
Но аналогичная проблема может возникнуть при запуске обновления системы — это странно, поскольку следующая команда начинает с обновления кэша, следовательно, кэш самый новый и ошибка «файл не найден» не должна возникать:
sudo pacman -Syu
Эта команда привела к ошибке:
error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirrors.evowise.com : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.rackspace.com : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.rackspace.com : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.dkm.cz : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from mirror.dkm.cz : The requested URL returned error: 404 error: failed retrieving file 'goaccess-1.4.5-1-x86_64.pkg.tar.zst' from europe.mirror.pkgbuild.com : The requested URL returned error: 404 .................................................................... .................................................................... .................................................................... warning: failed to retrieve some files error: failed to commit transaction (failed to retrieve some files) Errors occurred, no packages were upgraded.
Многократное повторение команды ничего не меняет.
Причина в следующем: pacman скачивает кэш с некачественного зеркала, в котором содержится неверная информация. Для исправления, нужно выбрать другое зеркало, или переместить другое зеркало вверх списка, если вы используете несколько зеркал.
Начнём с того, что переключимся на новый список зеркал. Дело в том, что при установке пакета pacman-mirrorlist (в этом пакете содержится список зеркал), новый файл /etc/pacman.d/mirrorlist не заменяет существующий, а сохраняется с именем /etc/pacman.d/mirrorlist.pacnew. То есть даже если у вас последняя версия пакета pacman-mirrorlist, это не означает, что у вас актуальная версия файла /etc/pacman.d/mirrorlist. Проверте, существует ли файл /etc/pacman.d/mirrorlist.pacnew:
ls -l /etc/pacman.d/mirrorlist.pacnew
Если файл существует, то выполните следующие две команды (в противном случае пропустите их):
sudo mv /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.back sudo mv /etc/pacman.d/mirrorlist.pacnew /etc/pacman.d/mirrorlist
Это не всё — дело в том, что в файле /etc/pacman.d/mirrorlist по умолчанию все зеркала закомментированы, то есть отключены. Чтобы это исправить, откройте данный файл:
sudo gedit /etc/pacman.d/mirrorlist
и раскомментируйте, то есть удалите символ # в начале строки. Выберите те зеркала и страны, которые ближе к вам.
В моём случае проблемным зеркалом, вызвавшим описанную выше ошибку, стало следующее (не используйте его):
#Server = http://mirrors.evowise.com/archlinux/$repo/os/$arch
Метаданные в файлах Word
В файле MS Word и вообще во всех офисных документах MS Office содержится множество метаданных.
И ещё:
Если нужно извлечь метаданные из файлов MS Word без открытия файла в редакторе Word, то можно воспользоваться специальными утилитами.
При этом популярный инструмент mat, который используется для показа и очистки метаданных, работает с файлами MS Word не очень хорошо:
mat -d file2.docx
Пример вывода:
File file2.docx :
Harmful metadata found:
customXml/item1.xml's zipinfo: {'system': 'unknown'}
docProps/core.xml's zipinfo: {'system': 'unknown'}
docProps/app.xml's zipinfo: {'system': 'unknown'}
word/document.xml's zipinfo: {'system': 'unknown'}
.xml's zipinfo: {'system': 'unknown'}
word/theme/theme1.xml's zipinfo: {'system': 'unknown'}
customXml/itemProps1.xml's zipinfo: {'system': 'unknown'}
_rels/.rels's zipinfo: {'system': 'unknown'}
customXml/_rels/item1.xml.rels's zipinfo: {'system': 'unknown'}
word/footnotes.xml's zipinfo: {'system': 'unknown'}
word/header1.xml's zipinfo: {'system': 'unknown'}
word/_rels/document.xml.rels's zipinfo: {'system': 'unknown'}
word/webSettings.xml's zipinfo: {'system': 'unknown'}
word/styles.xml's zipinfo: {'system': 'unknown'}
docProps/core.xml: harmful content
word/numbering.xml's zipinfo: {'system': 'unknown'}
word/fontTable.xml's zipinfo: {'system': 'unknown'}
word/endnotes.xml's zipinfo: {'system': 'unknown'}
word/settings.xml's zipinfo: {'system': 'unknown'}
docProps/app.xml: harmful content
На самом деле, мало что понятно и показанная информация кажется скорее мусором. Но полезные данные имеются, это строки:
docProps/core.xml: harmful content docProps/app.xml: harmful content
В них говориться, что файлы docProps/core.xml и docProps/app.xml содержат потенциально пагубное содержимое. Но самих данных с помощью этой программы мы увидеть не можем.
Если попытаться проанализировать файл .docm (документ MS Word с поддержкой макросов):
mat -d file2.docm
То программа просто напишет, что не может обработать этот файл:
Unable to process file2.docm
Это при том, что формат .docm имеет минимальное отличие от формата .docx — пара дополнительных файлов внутри (с описанием макросов и второй файл с самими макросами).
Имеется ещё одна версия mat2. Попробуем её:
mat2 -s file2.docx
Пример вывода:
Metadata for file2.docx:
Metadata for .xml:
create_system: Weird
Metadata for _rels/.rels:
create_system: Weird
Metadata for customXml/_rels/item1.xml.rels:
create_system: Weird
Metadata for customXml/item1.xml:
create_system: Weird
Metadata for customXml/itemProps1.xml:
create_system: Weird
Metadata for docProps/app.xml:
AppVersion: 16.0000
Application: Microsoft Office Word
Characters: 275
CharactersWithSpaces: 300
DocSecurity: 0
HeadingPairs: <vt:vector size="2" baseType="variant"><vt:variant><vt:lpstr>Название</vt:lpstr></vt:variant><vt:variant><vt:i4>1</vt:i4></vt:variant></vt:vector>
HyperlinksChanged: false
Lines: 76
LinksUpToDate: false
Pages: 6
Paragraphs: 31
ScaleCrop: false
SharedDoc: false
Template: Normal
TitlesOfParts: <vt:vector size="1" baseType="lpstr"><vt:lpstr></vt:lpstr></vt:vector>
TotalTime: 16
Words: 50
create_system: Weird
Metadata for docProps/core.xml:
cp:lastModifiedBy: MiAl
cp:lastPrinted: 2019-07-18T02:58:00Z
cp:revision: 9
create_system: Weird
dc:creator: Alex
Metadata for word/_rels/document.xml.rels:
create_system: Weird
Metadata for word/document.xml:
create_system: Weird
Metadata for word/endnotes.xml:
create_system: Weird
Metadata for word/fontTable.xml:
create_system: Weird
Metadata for word/footnotes.xml:
create_system: Weird
Metadata for word/header1.xml:
create_system: Weird
Metadata for word/numbering.xml:
create_system: Weird
Metadata for word/settings.xml:
create_system: Weird
Metadata for word/styles.xml:
create_system: Weird
Metadata for word/theme/theme1.xml:
create_system: Weird
Metadata for word/webSettings.xml:
create_system: Weird
Здесь всё намного лучше, выведены почти все метаданные файла.
Попробуем проанализировать формат .docm:
mat2 -s file2.docm
Опять неудача:
file2.docm's format (application/vnd.ms-word.document.macroenabled.12) is not supported
Конфигурационные файлы репозиториев (*.repo)
Все конфигурационные файлы репозиториев расположены в директории /etc/yum.repos.d/. В конфигурационных файл *.repo. Типовой конфигурационный файл репозитория содержит следующие параметры:
- name — имя репозитория;
- baseurl — ссылка на репозиторий (может быть ftp://address, http://address, https://address или file://address для локального репозитория);
- enabled – нужно ли использовать данный репозиторий: 1 – репозиторий подключен, 0 – отключен;
- async – использовать ли параллельную загрузку пакетов (auto/on/off);
- gpgcheck – нужно ли выполнять проверку GPG (1 – проверять);
- gpgkey — ссылка на GPG ключ;
- exclude — список исключенных пакетов;
- includepkgs — список включенных пакетов;
- mirrorlist – список зеркал репозитория.
В минимальном случае repo файл может выглядеть так:
name=rep_name baseurl=rep_url
Например, после подключения репозитория REMII, в директории репозиториев появится несколько конфигурационных файлов Remi (remi-*.repo).
Как вы видите, Remi имеет отдельный конфигурационный файл для каждой версии php. Вам нужно включить нужную вам версию в конфигурационном файле, например у меня на сервере будет стоять версия php 7.3, для этого я включил именно этот репозиторий (в файле remi-php73.repo указал enabled=1):
Вы можете подключит репозиторий вручную, для этого нужно создать конфигурационный файл репозитория в директории /etc/yum.repos.d/. Подключим репозиторий MaruaDB.
Добавим в него данные, которое нам предоставляет разработчик пакета MariaDB:
name = MariaDB baseurl = http://yum.mariadb.org/10.4/centos73-amd64/ gpgkey=https://yum.mariadb.org/RPM-GPG-KEY-MariaDB gpgcheck=1
Репозитории в CentOS
Для начала давайте поясним, что такое репозитории и для чего они нужны. Вот что говорит wikipedia на этот счет:
Некоторое время назад Linux приложения выходили в виде исходного кода, который потом компилировали на сервере и получали готовые программы. На сегодняшний день большинство приложений выходят в виде так называемых пакетов. Это уже собранные приложения, которые можно сразу установить и пользоваться.
В нашем случае репозиторий — хранилище пакетов для операционной системы CentOS. Существуют repository от разработчика системы, их называют официальные. Набор rpm пакетов там обычно ограничен и версии не самые свежие. Для установки дополнительного софта используют сторонние репозитории. Их поддерживать могут как другие компании, так и группы энтузиастов.
Управлением пакетами и репозиториями в CentOS занимается утилита yum. Ее конфигурационный файл находится в /etc/yum.conf. Этот файл содержит секцию , в которой указываются глобальные настройки программы. Так же он может содержать одну или несколько секций , в которой хранятся настройки репозиториев. Тем не менее, рекомендуется информацию о репозиториях хранить в каталоге /etc/yum.repos.d/ в специальных файлах .repo.
Минимальное содержание файла .repo следующее:
name=repository_name baseurl=repository_url
| name | имя, описывающее репозиторий, может быть любым |
| baseurl | ссылка на расположение репозитория, может быть в виде http, ftp или file ссылки |
Другие ползные параметры, которые могут быть указаны в repo файле:
| enabled | принимает значение 1 или 0, 1 — репозиторий подключен, 0 — отключен |
| async | управляет загрузкой пакетов, auto — использует при возможности параллельную загрузку, on — использует только параллельную загрузку, off — параллельная загрузка отключена |
| mirrorlist | вместо ссылки на конкретный адрес репозитория может быть указана ссылка на список адресов, из которых при установке будет выбран наиболее подходящий |
| gpgcheck | принимает значение 1 или 0, 1- осуществлять проверку GPG подписи пакета из репозитория, 0 — не проверять |
| gpgkey | ссылка на GPG ключ репозитория |
Вот содержание стандартного файла с репозиториями CentOS /etc/yum.repos.d/CentOS-Base.repo:
name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 #released updates name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 #additional packages that may be useful name=CentOS-$releasever - Extras mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 #additional packages that extend functionality of existing packages name=CentOS-$releasever - Plus mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
Удалить репозиторий в CentOS
Для того, чтобы удалить репозиторий из системы, необходимо узнать его id с помощью команды yum repolist. Об этом я писал в предыдущем разделе. Затем с помощью утилиты yum-config-manager, которая входит в пакет yum-utils выполним удаление:
# yum-config-manager --disable remi-safe bash: yum-config-manager: command not found
Если получаете такую ошибку, то установите пакет yum-utils:
# yum -y install yum-utils
Удаление репозитория в centos:
# yum-config-manager --disable remi-safe
Теперь проверяем список активных репозиториев:
Удаленного репозитория remi-safe нет. Значит все в порядке, отключение репозитория прошло успешно.
Для того, чтобы обновить кэш yum после изменения репозиториев, можно воспользоваться следующими командами:
Очистить кеш:
# yum clean all
Пересоздать кеш:
# yum makecache
Почему не получается сделать в Инстаграме репост записи в истории?
Не все знают, что сейчас можно сделать репост в Инстаграм в историю. Тем не менее, сейчас необязательно даже качать специальный софт для этого – нужная кнопка доступна в стандартном интерфейсе. Но почему нельзя, не работает перепост? Само собой, самая распространённая проблема – устаревшая версия приложения. Это – частая неполадка, которая мешает использованию нового функционала. Ещё одна причина – сам пользователь не разрешил. Если репост не делается, эта опция была запрещена владельцем аккаунта.
Конечно, в копировании чужого контента это не поможет, но я расскажу, что нужно сделать, чтобы другие люди при желании могли репостить ваши сториз:
- Жмём по иконке с человеком в правом нижнем углу.
- Сверху справа выбираем кнопку с тремя горизонтальными линиями.
- Переходим в настройки.
- Открываем вкладку «Конфиденциальность».
- Жмём по пункту «История».
- Прокручиваем ниже, до вкладки «Поделиться», и делаем активным пункт про перепосты в истории. При желании вы можете запретить даже делиться в сообщениях.
Эта инструкция вам не очень поможет пробить брешь в безопасности социальной сети. Если поделиться записью человека очень нужно, так и напишите ему, «Не могу сделать репост, включи эту возможность». Или воспользуйтесь сторонними приложениями.
Изменение фона сторис в социальной сети
Мы разобрались, как отредактировать историю в Инстаграме после публикации. Теперь поговорим о редактировании фона Историй. Изменение фоновой части проводится из-за размещения важных текстов или же активных ссылок на сторонние ресурсы или каналы. Чтобы внести коррективы, требуется:
Сделать фотографию или снять видеоролик
Важно делать это в стандартном режиме.
Запустить режим рисования, выбрать необходимый оттенок, а также рабочий инструмент.
Кликнуть по любой области изображения для заливки.
Кликнуть по клавише «Готово», сохранить результат и далее редактировать запись, добавляя текст, ссылку и т.д.
Обратите внимание, что изменение фоновой части возможно лишь частично. С этой целью пользователям доступен особый ластик, который расположен в левом верхнем углу экрана
Он стирает лишь часть заливки и открывает нужную область снимка. Также ластик успешно применяется при создании и редактуре текстовой части.
В разделе «Актуальных» редактура заливкой также разрешена. С этой целью открывайте дополнительное меню и изменяйте фотографии на свой лад в режиме редакции.
Таким образом, мы рассказали о том, как отредактировать сторис в Инсте после отправки. С начала появления в социальной сети был сильно ограничен функционал. Основное предназначение Инстаграм на тот момент – публикация фотографий в открытый доступ с мобильных устройств. Постепенно функции добавлялись, их становилось все больше. Также наблюдался прирост пользователей, заинтересованных новыми опциями. Теперь пользователям доступен целый мир корректив, деталей, функций, способствующих ведению личных блогов или же бизнеса в сети.
Вопросы наших читателей
Больше упоминаний вашего аккаунта – больше посетителей страницы и потенциальных подписчиков. Можно, например, устроить розыгрыш и поставить условием срепостить эту запись.
Во-первых, конечно, они позволяют вбить контент-план на месяц и забыть о создании публикаций вручную. Вторая их важная фишка – возможность вести одновременно несколько социальных сетей, при этом не тратя огромное количество времени.
Как истории, так и публикации, но поделиться получится только в сториз. Если нужно сделать перепост именно в качестве нового поста, придётся либо воспользоваться сторонним софтом, либо сделать скриншот и опубликовать его, обрезав.
Чтобы задать вопрос или высказать мнение – пишите в . А также смотрите полезное видео по теме.
Создание репозитория
Настроим свой репозиторий, в котором будут храниться установочные пакеты. Также настроим их автоматическую синхронизацию с репозиторием CentOS.
Устанавливаем необходимые утилиты для работы с локальным репозиторием:
yum install createrepo yum-utils
Создаем каталоги для репозитория:
mkdir -p /usr/share/nginx/html/repos/7/{os,updates}/x86_64
* в данном примере будет создан каталог /usr/share/nginx/html/repos/7, а внутри него каталоги os (стандартный репозиторий для установка пакетов) и updates (обновления), в каждой из которых каталог x86_64 (для систем x64 архитектуры x86).
Синхронизируем наш будущий репозиторий с источником пакетов, например, с зеркалом от Яндекса:
rsync -iavrt —delete —exclude=’repo*’ rsync://mirror.yandex.ru/centos/7/os/x86_64/ /usr/share/nginx/html/repos/7/os/x86_64/
… ждем …
После синхронизируем updates:
rsync -iavrt —delete —exclude=’repo*’ rsync://mirror.yandex.ru/centos/7/updates/x86_64/ /usr/share/nginx/html/repos/7/updates/x86_64/
Создаем репозитории:
createrepo -v /usr/share/nginx/html/repos/7/os/x86_64
createrepo -v /usr/share/nginx/html/repos/7/updates/x86_64
А также разрешаем группы:
createrepo /usr/share/nginx/html/repos/7/os/x86_64 -g /usr/share/nginx/html/repos/7/os/x86_64/repodata/repomd.xml
createrepo /usr/share/nginx/html/repos/7/updates/x86_64 -g /usr/share/nginx/html/repos/updates/os/x86_64/repodata/repomd.xml
* в некоторых репозиториях файл repomd.xml может иметь другое название, например, comps.xml.
Настраиваем nginx:
vi /etc/nginx/conf.d/default.conf
…
location / {
root /usr/share/nginx/html;
index index.html index.htm;
autoindex on;
}
…
* в данном примере мы добавили autoindex on для удобства — это позволит просматривать содержимое репозитория в браузере.
Перезапускаем nginx:
systemctl restart nginx
Открываем браузер и переходим по адресу http://<IP-адрес сервера>/repos/7 — мы должны увидеть список os и updates. Походив по нему, мы найдем список скачанных пакетов.
Yandex mirror для CentOS
mirror.yandex.ru — сайт компании Яндекс, зеркало репозитариев популярных дистрибутивов Linux, FreeBSD и других проектов, в том числе CentOS. Работает по протоколам HTTP, FTP и rsync.
На зеркале CentOS можно скачать дистрибутивы всех актуальных на текущий момент версий, а это версии 5, 6 и 7. Зеркало можно использовать в качестве источников стандартных репозиториев системы — base, updates, extras, centosplus.
Можно использовать, что я неоднократно делал, yandex mirror для сетевой установки CentOS. Путь к установочному образу: http://mirror.yandex.ru/centos/7/os/x86_64/images/
Редактирование без удаления Истории из ленты
Все перечисленные методы не отвечают на вопрос, как редактировать сторис в Инстаграм после публикации. Они работают лишь при непосредственной публикации постов. Однако есть один способ внесения изменений в пост уже после публикации. Редактирование открывается вновь в процессе перенесения Истории в новый раздел «Актуальное». Для перенесения требуется:
- Снять новый видеоролик или сделать фотографию.
- В редакторе добавить необходимые фильтры, стикеры и проч.
- Сохранить внесенные изменения, опубликовать в Истории.
- Открыть «Актуальные», кликнуть по клавише «+».
- Добавить туда опубликованную Историю, внести необходимые коррективы, удалять или добавлять лишние изображения.
- Сохранить и опубликовать готовый результат в разделе «Актуальное».
Мак мы разобрались с вопросом, как редактировать историю в Инстаграме, не удаляя. Доступ к посту станет доступным все время. Публикация будет выглядеть как альбом
Обратите внимание, что вывод в «Актуальное» возможен только после перенесения сторис в раздел архива. Для просмотра архива откройте меню, показанное как закругленная стрелочка
Инструкция по дальнейшим действиям, как редактировать Историю в Инстаграме после публикации указана выше.
Репозитории в CentOS
Для начала давайте поясним, что такое репозитории и для чего они нужны. Вот что говорит wikipedia на этот счет:
Некоторое время назад Linux приложения выходили в виде исходного кода, который потом компилировали на сервере и получали готовые программы. На сегодняшний день большинство приложений выходят в виде так называемых пакетов. Это уже собранные приложения, которые можно сразу установить и пользоваться.
В нашем случае репозиторий — хранилище пакетов для операционной системы CentOS. Существуют repository от разработчика системы, их называют официальные. Набор rpm пакетов там обычно ограничен и версии не самые свежие. Для установки дополнительного софта используют сторонние репозитории. Их поддерживать могут как другие компании, так и группы энтузиастов.
Управлением пакетами и репозиториями в CentOS занимается утилита yum. Ее конфигурационный файл находится в /etc/yum.conf. Этот файл содержит секцию , в которой указываются глобальные настройки программы. Так же он может содержать одну или несколько секций , в которой хранятся настройки репозиториев. Тем не менее, рекомендуется информацию о репозиториях хранить в каталоге /etc/yum.repos.d/ в специальных файлах .repo.
Минимальное содержание файла .repo следующее:
name=repository_name baseurl=repository_url
| name | имя, описывающее репозиторий, может быть любым |
| baseurl | ссылка на расположение репозитория, может быть в виде http, ftp или file ссылки |
Другие ползные параметры, которые могут быть указаны в repo файле:
| enabled | принимает значение 1 или 0, 1 — репозиторий подключен, 0 — отключен |
| async | управляет загрузкой пакетов, auto — использует при возможности параллельную загрузку, on — использует только параллельную загрузку, off — параллельная загрузка отключена |
| mirrorlist | вместо ссылки на конкретный адрес репозитория может быть указана ссылка на список адресов, из которых при установке будет выбран наиболее подходящий |
| gpgcheck | принимает значение 1 или 0, 1- осуществлять проверку GPG подписи пакета из репозитория, 0 — не проверять |
| gpgkey | ссылка на GPG ключ репозитория |
Вот содержание стандартного файла с репозиториями CentOS /etc/yum.repos.d/CentOS-Base.repo:
name=CentOS-$releasever - Base mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=os gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 #released updates name=CentOS-$releasever - Updates mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=updates gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 #additional packages that may be useful name=CentOS-$releasever - Extras mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=extras gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7 #additional packages that extend functionality of existing packages name=CentOS-$releasever - Plus mirrorlist=http://mirrorlist.centos.org/?release=$releasever&arch=$basearch&repo=centosplus gpgcheck=1 enabled=0 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-7
