From: "Dmitry V. Levin" <ldv@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] [sisyphus] приключения resolv.conf в ALT
Date: Fri, 3 Apr 2020 16:28:18 +0300
Message-ID: <20200403132818.GB12472@altlinux.org> (raw)
In-Reply-To: <5ad05ca4-e829-d1bc-c962-ff50eeb56294@altlinux.org>
On Fri, Apr 03, 2020 at 04:21:52PM +0300, Denis Medvedev wrote:
> 03.04.2020 16:10, Dmitry V. Levin пишет:
> > On Fri, Apr 03, 2020 at 03:56:04PM +0300, Andrey Savchenko wrote:
> >> On Fri, 3 Apr 2020 15:20:23 +0300 Dmitry V. Levin wrote:
> >>> On Fri, Apr 03, 2020 at 01:51:51PM +0300, Denis Medvedev wrote:
> >>>> 03.04.2020 13:50, Vladimir D. Seleznev пишет:
> >>>>> On Fri, Apr 03, 2020 at 01:37:41PM +0300, Vladimir D. Seleznev wrote:
> >>>>>> On Fri, Apr 03, 2020 at 01:32:38PM +0300, Denis Medvedev wrote:
> >>>>>>> 03.04.2020 13:28, Vladimir D. Seleznev пишет:
> >>>>>>>> On Tue, Mar 31, 2020 at 10:05:17PM +0300, Alexey Shabalin wrote:
> >>>>>>>>>> PS: следующим письмом попробую подробно описать наши кувыркания с resolv.conf.
> >>>>>>>>>> дождитесь его, прежде чем отвечать :)
> >>>>>>>>> 5) update_chrooted.
> >>>>>>>>> Наши замечательные ALT особенности :)
> >>>>>>>>> Множество сервисов и отдельных программ(например ping) запускаются в chroot.
> >>>>>>>>> В этот chroot должны быть скопированы и библиотеки, и настройки для
> >>>>>>>>> этих библиотек, в частности resolv.conf.
> >>>>>>>>> Т.е. ping не использует /etc/resolv.conf, а использует
> >>>>>>>>> /var/resolv/etc/resolv.conf.
> >>>>>>>>> Нам очень важно держать в chroot'ах resolv.conf синхронным c с
> >>>>>>>>> основной системой.
> >>>>>>>>> Вроде все утилиты, обновляющие /etc/resolv.conf обучены вызывать
> >>>>>>>>> update_chrooted.
> >>>>>>>> Может быть стоит написать некий update_chrootd, который следил бы за
> >>>>>>>> всеми файлами, которые должны быть в чруте, и при их обновлении обновлял
> >>>>>>>> бы чрут? rpm -qf *
> >>>>>>>> файл /var/lib/ldap/usr/lib/libcom_err.so.2 не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libdb-4.7.so не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libgssapi_krb5.so.2 не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libk5crypto.so.3 не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libkeyutils.so.1 не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libkrb5.so.3 не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libkrb5support.so.0 не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libm.so.6 не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libodbc.so.2 не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libpcre.so.3 не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libperl-5.28.so не принадлежит ни одному из пакетов
> >>>>>>>> файл /var/lib/ldap/usr/lib/libselinux.so.1 не принадлежит ни одному из пакетов
> >>>>>>>> openldap-servers-2.4.48-alt3.x86_64
> >>>>>>>> openldap-servers-2.4.48-alt3.x86_64
> >>>>>>>>
> >>>>>>>>
> >>>>>>> Делать inotify на список файлов относящимся к chroot и по событию
> >>>>>>> изменения делать update_chroot?
> >>>>>> Да.
> >>>>> Нет, при текущей архитектуре update_chrooted предложенное мной решение
> >>>>> невозможно. Для него надо с нуля придумывать всё решение. И если для
> >>>>> postfix'а нельзя декларативно указать все его конфиги, то боюсь в общем
> >>>>> случае это будет невозможно.
> >>>>>
> >>>> Хотелось бы прописать политику о том, что любой пакет, желающий
> >>>> использовать chroot, должен иметь возможность работать БЕЗ chroot.
>
> Наличие чрута приводит к вот такой ситуации:
>
> rpm -qf *
> файл /var/lib/ldap/usr/lib/libcom_err.so.2 не принадлежит ни одному из
> пакетов
> файл /var/lib/ldap/usr/lib/libdb-4.7.so не принадлежит ни одному из пакетов
> файл /var/lib/ldap/usr/lib/libgssapi_krb5.so.2 не принадлежит ни одному
> из пакетов
> файл /var/lib/ldap/usr/lib/libk5crypto.so.3 не принадлежит ни одному из
> пакетов
> файл /var/lib/ldap/usr/lib/libkeyutils.so.1 не принадлежит ни одному из
> пакетов
> файл /var/lib/ldap/usr/lib/libkrb5.so.3 не принадлежит ни одному из пакетов
> файл /var/lib/ldap/usr/lib/libkrb5support.so.0 не принадлежит ни одному
> из пакетов
> файл /var/lib/ldap/usr/lib/libm.so.6 не принадлежит ни одному из пакетов
> файл /var/lib/ldap/usr/lib/libodbc.so.2 не принадлежит ни одному из пакетов
> файл /var/lib/ldap/usr/lib/libpcre.so.3 не принадлежит ни одному из пакетов
> файл /var/lib/ldap/usr/lib/libperl-5.28.so не принадлежит ни одному из
> пакетов
> файл /var/lib/ldap/usr/lib/libselinux.so.1 не принадлежит ни одному из
> пакетов
> openldap-servers-2.4.48-alt3.x86_64
> openldap-servers-2.4.48-alt3.x86_64
>
> И как мне правильно проверять целостность таких файлов относительно базы
> rpm? Это файлы с исполняемым кодом.
Вы как будто предлагаете лечить насморк методом декапитации?
--
ldv
next prev parent reply other threads:[~2020-04-03 13:28 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 10:28 ` Vladimir D. Seleznev
2020-04-03 10:32 ` Denis Medvedev
2020-04-03 10:37 ` Vladimir D. Seleznev
2020-04-03 10:50 ` Vladimir D. Seleznev
2020-04-03 10:51 ` Denis Medvedev
2020-04-03 12:20 ` Dmitry V. Levin
2020-04-03 12:22 ` Denis Medvedev
2020-04-03 12:33 ` Alexey V. Vissarionov
2020-04-03 12:56 ` Andrey Savchenko
2020-04-03 13:10 ` Dmitry V. Levin
2020-04-03 13:21 ` Denis Medvedev
2020-04-03 13:28 ` Dmitry V. Levin [this message]
2020-04-03 13:50 ` Alexey V. Vissarionov
2020-04-03 13:46 ` Vladimir D. Seleznev
2020-04-03 16:53 ` Andrey Savchenko
2020-04-03 18:09 ` Vladimir D. Seleznev
2020-04-03 10:32 ` Alexey V. Vissarionov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200403132818.GB12472@altlinux.org \
--to=ldv@altlinux.org \
--cc=devel@lists.altlinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git