Re: proftpd + inetd + ssl/tls и другие вопросы.
Oleksandr Gavenko -> debian-russian@lists.debian.org @ Tue, 24 Nov 2015 02:30:58 +0200: OG> Выяснил что plain ftp передает пароль в открытом виде в момент авторизации. OG> Есть https://ru.wikipedia.org/wiki/FTPS в разных версиях / режимах работы. OG> Не могу вьехать что делать что бы proftpd + inetd работал безопасно. OG> В общем на сервере выполнил: OG> $ sudo proftpd-gencert OG> /etc/proftpd/proftpd.conf:: OG> Include /etc/proftpd/tls.conf OG> /etc/proftpd/tls.conf:: OG> TLSEngine on OG> TLSLog /var/log/proftpd/tls.log OG> TLSProtocol SSLv23 По нынешним временам SSL v2 и v3 считается за "шифрование отсутствует". В смысле, дыры и их эксплойты в этих версиях протокола известны. OG> TLSRSACertificateFile /etc/ssl/certs/proftpd.crt OG> TLSRSACertificateKeyFile/etc/ssl/private/proftpd.key OG> TLSOptions NoCertRequest EnableDiags OG> TLSVerifyClient off OG> TLSRequired on OG> Пробую: OG> bash# lftp ftp://user@vps OG> Password: OG> lftp user@vps:~> ls OG> ls: Fatal error: Certificate verification: Not trusted OG> lftp user@vps:~> exit OG> bash# lftp -e 'set ssl:verify-certificate no' ftp://user@vps OG> Password: OG> lftp user@vps:~> ls OG> drwxr-xr-x 5 user user 4096 Nov 22 18:04 devel OG> drwxr-xr-x 2 user user 4096 Oct 10 16:14 tmp OG> Обычная команда `ftp` из `/usr/bin/netkit-ftp` не поддерживает SSL: OG> bash# ftp -n vps OG> Connected to vps. OG> 220 ProFTPD 1.3.5 Server (Debian) [149.202.132.30] ftp>> ls OG> 550 SSL/TLS required on the control channel OG> ftp: bind: Address already in use ftp>> user user OG> ^C OG> 421 Service not available, remote server has closed connection ftp>> exit OG> `curl` тоже работает:: OG> $ curl --ftp-ssl -k --netrc ftp://user@vps/.bashrc OG> Нужно ли в inetd.conf использовать ftps или ftp: OG> ftpstream tcp nowait root /usr/sbin/tcpd /usr/sbin/proftpd OG> ftpsstream tcp nowait root /usr/sbin/tcpd /usr/sbin/proftpd OG> У меня на ftps ошибки: OG> bash# curl --ftp-ssl -k --netrc ftps://user@vps/.bashrc OG> curl: (35) gnutls_handshake() failed: An unexpected TLS packet was received. OG> bash# lftp ftps://user@vps OG> lftp user@vps:~> ls OG> ls: Fatal error: gnutls_handshake: An unexpected TLS packet was received. OG> Такое ощущение что для ftps:// используется другой протокол, чем на ftp:// с OG> включенным SSL. Да. ftps начинается с SSL/TLS handshake, и уже только после того, как защищенное соединение установилось, начинается диалог по протоколу FTP. В случае с ftp сначала начинается диалог по FTP, внутри него выдается просьба поднять TLS, и после того, как он поднят, продолжается диалог по FTP. OG> Как правильно запретить общение открытым текстом и настроить SSL/TLS в proftpd? По идее, при настройке TLSRequired on разницы в безопасности быть не должно - FTP не поддерживает вроде бы pipelining, на USER сервер выдаст вон то, что он выдает команде ftp, и до пароля дело не дойдет. OG> Далее вопрос как в Debian сделать публичный ключ proftpd доверенным на OG> клиентах? OG> Я пробовал как: OG> $ sudo mkdir /usr/share/ca-certificates/vps OG> $ sudo scp user@vps:/etc/ssl/certs/proftpd.crt /usr/share/ca-certificates/vps/proftpd.crt OG> $ sudo dpkg-reconfigure ca-certificates OG> $ sudo update-ca-certificates --fresh OG> Но curl и lftp игнорируют Дебиановские соглашения о сертификатах. Или я OG> неверно готовлю. При том proftpd.crt виден в конце: Второе. Тут, вероятно, для начала нужен некоторый ликбез. Клиенты доверяют сертификату сервера, если этот сертификат подписан доверенным центром сертификации. Вот то самое "ca" в ca-certificates. Certification Authority. У CA тоже есть сертификат, и подпись на сертификате сервера проверяется об этот сертификат (там содержится открытый ключ подписи). Для построения цепочки доверия нужно выполнение нескольких условий. Применительно к твоей ситуации, не выполнено в первую очередь условие "сертификат сервера и сертификат CA - разные сертификаты, с разными разрешенными областями применения". Чтобы нормально работало, надо сделать честный сертификат CA, распространить его по клиентам, в норме - установить в набор доверенных корневых (это то, что ты пытался сделать с сертификатом сервера), сделать честный серверный сертификат и подписать его ключом CA. Или купить серверный сертификат у какого-нибудь известного CA, про которого большинство клиентов знает из коробки. Это минус необходимость устанавливать свой сертификат CA на клиентов - довольно сложная операция для юзера на винде (вероятно, разная для разных версий винды), работоспособная не в каждом андроиде, и т.п.
Re: proftpd + inetd + ssl/tls и другие вопросы.
On 23/11/15 07:30 PM, Oleksandr Gavenko wrote: bash# lftp ftp://user@vps Password: lftp user@vps:~> ls ls: Fatal error: Certificate verification: Not trusted lftp user@vps:~> exit тут бы я посмотрел на ftp:ssl-* значения curl попробовать с -k и смотреть как работает SSL соединение с помощью openssl openssl s_client -connect vps:990
Re: proftpd + inetd + ssl/tls и другие вопросы.
On 23/11/15 07:30 PM, Oleksandr Gavenko wrote: bash# lftp ftp://user@vps Password: lftp user@vps:~> ls ls: Fatal error: Certificate verification: Not trusted lftp user@vps:~> exit тут бы я посмотрел на ftp:ssl-* значения curl попробовать с -k и смотреть как работает SSL соединение с помощью openssl openssl s_client -connect vps:990
Re: proftpd + inetd + ssl/tls и другие вопросы.
On 23/11/15 07:30 PM, Oleksandr Gavenko wrote: Выяснил что plain ftp передает пароль в открытом виде в момент авторизации. Есть https://ru.wikipedia.org/wiki/FTPS в разных версиях / режимах работы. Не могу вьехать что делать что бы proftpd + inetd работал безопасно. а SFTP или Rsync over SSH не нравится ?
proftpd + inetd + ssl/tls и другие вопросы.
Выяснил что plain ftp передает пароль в открытом виде в момент авторизации. Есть https://ru.wikipedia.org/wiki/FTPS в разных версиях / режимах работы. Не могу вьехать что делать что бы proftpd + inetd работал безопасно. В общем на сервере выполнил: $ sudo proftpd-gencert /etc/proftpd/proftpd.conf:: Include /etc/proftpd/tls.conf /etc/proftpd/tls.conf:: TLSEngine on TLSLog /var/log/proftpd/tls.log TLSProtocol SSLv23 TLSRSACertificateFile /etc/ssl/certs/proftpd.crt TLSRSACertificateKeyFile/etc/ssl/private/proftpd.key TLSOptions NoCertRequest EnableDiags TLSVerifyClient off TLSRequired on Пробую: bash# lftp ftp://user@vps Password: lftp user@vps:~> ls ls: Fatal error: Certificate verification: Not trusted lftp user@vps:~> exit bash# lftp -e 'set ssl:verify-certificate no' ftp://user@vps Password: lftp user@vps:~> ls drwxr-xr-x 5 user user 4096 Nov 22 18:04 devel drwxr-xr-x 2 user user 4096 Oct 10 16:14 tmp Обычная команда `ftp` из `/usr/bin/netkit-ftp` не поддерживает SSL: bash# ftp -n vps Connected to vps. 220 ProFTPD 1.3.5 Server (Debian) [149.202.132.30] ftp> ls 550 SSL/TLS required on the control channel ftp: bind: Address already in use ftp> user user ^C 421 Service not available, remote server has closed connection ftp> exit `curl` тоже работает:: $ curl --ftp-ssl -k --netrc ftp://user@vps/.bashrc Нужно ли в inetd.conf использовать ftps или ftp: ftpstream tcp nowait root /usr/sbin/tcpd /usr/sbin/proftpd ftpsstream tcp nowait root /usr/sbin/tcpd /usr/sbin/proftpd У меня на ftps ошибки: bash# curl --ftp-ssl -k --netrc ftps://user@vps/.bashrc curl: (35) gnutls_handshake() failed: An unexpected TLS packet was received. bash# lftp ftps://user@vps lftp user@vps:~> ls ls: Fatal error: gnutls_handshake: An unexpected TLS packet was received. Такое ощущение что для ftps:// используется другой протокол, чем на ftp:// с включенным SSL. Как правильно запретить общение открытым текстом и настроить SSL/TLS в proftpd? Далее вопрос как в Debian сделать публичный ключ proftpd доверенным на клиентах? Я пробовал как: $ sudo mkdir /usr/share/ca-certificates/vps $ sudo scp user@vps:/etc/ssl/certs/proftpd.crt /usr/share/ca-certificates/vps/proftpd.crt $ sudo dpkg-reconfigure ca-certificates $ sudo update-ca-certificates --fresh Но curl и lftp игнорируют Дебиановские соглашения о сертификатах. Или я неверно готовлю. При том proftpd.crt виден в конце: /etc/ssl/certs/ca-certificates.crt Также если кормить напрямую: bash# curl -v --ftp-ssl --cacert /usr/share/ca-certificates/vps/proftpd.crt --netrc ftp://user@vps/.bashrc * Trying 149.202.132.30... * Connected to vps (149.202.132.30) port 21 (#0) < 220 ProFTPD 1.3.5 Server (Debian) [149.202.132.30] > AUTH SSL < 234 AUTH SSL successful * found 1 certificates in /usr/share/ca-certificates/vps/proftpd.crt * found 728 certificates in /etc/ssl/certs * ALPN, offering http/1.1 * SSL connection using TLS1.2 / ECDHE_RSA_AES_128_GCM_SHA256 * server certificate verification failed. CAfile: /usr/share/ca-certificates/vps/proftpd.crt CRLfile: none * Closing connection 0 curl: (60) server certificate verification failed. CAfile: /usr/share/ca-certificates/vps/proftpd.crt CRLfile: none More details here: http://curl.haxx.se/docs/sslcerts.html curl performs SSL certificate verification by default, using a "bundle" of Certificate Authority (CA) public keys (CA certs). If the default bundle file isn't adequate, you can specify an alternate file using the --cacert option. If this HTTPS server uses a certificate signed by a CA represented in the bundle, the certificate verification probably failed due to a problem with the certificate (it might be expired, or the name might not match the domain name in the URL). If you'd like to turn off curl's verification of the certificate, use the -k (or --insecure) option. -- Best regards!
Re: вопрос по .xsession-errors
Oleksandr Gavenko writes: > On 2015-11-23, Oleksandr Gavenko wrote: > > Это не поможет топикстартеру, но интересно было разобраться, а то смешно, > когда то на работе в цикле грепали ps: > > while true; > ps -e | grep COND > sleep 1 > done Спасибо. Это целая пушка для моего воробья. Сначала исключением угадал с первого раза. А потом еще и закладку сделал. Закладка сработала и указала на awesome. А анализ конфига привел к библиотеке obvious, автор которой и дергал неосторожно iwconfig (пока поставил на него линк в ~/bin в качестве костыля). В общем-то изменения формата конфигурационных файлов с каждой версией awesome как-бы намекают на некоторую сырость продукта. И, вместе с этим, лучшей альтернативы пока не вижу. И не очень-то хочу, чтобы в стабильную ветку приползло обновление. Когда все уже настроено под себя...
Re: вопрос по .xsession-errors
On 2015-11-23, Oleksandr Gavenko wrote: > Я попробовал: > > $ sudo auditctl -w /tmp -p w > > При старте xterm в логе есть строчка: > > type=SYSCALL msg=audit(1448308853.684:34): arch=c03e syscall=87 > success=yes exit=0 a0=24218a0 a1=7ffe55d12880 a2=7ffe55d12880 > a3=7ffe55d12640 items=2 ppid=3522 pid=12342 auid=4294967295 uid=1000 > gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 > tty=(none) ses=4294967295 comm="xterm" exe="/usr/bin/xterm" key=(null) > > Тут у нас pid, ppid, uid, gid, а также: > > comm="xterm" exe="/usr/bin/xterm" > > что очень удобно для быстро исчезающих скриптов. Я боялся что не будет имени исполняемого файла. Есть lastcomm из пакета acct (который также запускает сервис): bash# lastcomm lastcomm user pts/3 0.00 secs Mon Nov 23 22:38 sh user pts/8 0.00 secs Mon Nov 23 22:37 awkuser pts/8 0.00 secs Mon Nov 23 22:37 seduser pts/8 0.00 secs Mon Nov 23 22:37 manuser pts/8 0.01 secs Mon Nov 23 22:37 Согласно ACCT(5): If the kernel is built with the process accounting option enabled (CONFIG_BSD_PROCESS_ACCT), then calling acct(2) starts process accounting, for example: acct("/var/log/pacct"); /var/log/pacct - бинарный файл, lastcomm помагает его читать. Мне очень жаль что нет полного пути к команде и нет опций запуска и нет PWD. Эта информация очень бы помогла в отладке. Можно попробовать стартовать пользователькую сесию с $ cat ~/.xinitrc ... strace -e execve -o ~/strace.log -f LASTCOMMAND Будет вылазить: bash# strace -e execve -f sh -c "/bin/echo ok" execve("/bin/sh", ["sh", "-c", "/bin/echo ok"], [/* 59 vars */]) = 0 Process 14651 attached [pid 14651] execve("/bin/echo", ["/bin/echo", "ok"], [/* 59 vars */]) = 0 ok [pid 14651] +++ exited with 0 +++ --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=14651, si_uid=1000, si_status=0, si_utime=0, si_stime=0} --- +++ exited with 0 +++ Там пытаться воспроизвести проблемную ситуацию. Текущий каталог мониторить по: $ strace -e chdir,execve -f xterm Далее нашел: $ sudo forkstat 23:06:33 exec 15004 /bin/bash -c exec xterm -e bash -i 23:06:33 exec 15004 xterm -e bash -i 23:06:33 fork 15004 parent xterm -e bash -i 23:06:33 fork 15005 child xterm -e bash -i 23:06:33 exec 15005 bash -i 23:06:33 fork 15005 parent bash -i 23:06:33 fork 15006 child bash -i 23:06:33 fork 15006 parent bash -i 23:06:33 fork 15007 child bash -i 23:06:33 exec 15007 dircolors -b /home/user/.dircolors 23:06:33 exit 15007 00.001 dircolors -b /home/user/.dircolors 23:06:33 exit 15006 00.001 bash -i 23:06:33 fork 15005 parent bash -i 23:06:33 fork 15008 child bash -i 23:06:33 fork 15008 parent bash -i 23:06:33 fork 15009 child bash -i 23:06:33 exec 15009 ls /etc/bash_completion.d 23:06:33 exit 15009 00.002 ls /etc/bash_completion.d ... Это не поможет топикстартеру, но интересно было разобраться, а то смешно, когда то на работе в цикле грепали ps: while true; ps -e | grep COND sleep 1 done -- Best regards!
Re: Как работает локальный DNS кеш?
On Mon, Nov 23, 2015 at 09:44:17PM +0200, Oleksandr Gavenko wrote: > Было удивительно что glibc не просто прослойка к ядру, но также выполняет > прикладные сервисы как разрешение имен. В libc традиционно есть масса функций, никак не завязанных на вызовы ядра. Например, обработка строк: sscanf, sprintf, strchr, strtok, index и т.д. > Я наивно полагал что этим занимается ядро или сторонняя служба... В ядро этот функционал помещать совершенно незачем. Три главные задачи ядра -- предоставление интерфейса к железу, деление общих ресурсов и разграничение доступа, а здесь ничего из этого не требуется. -- Eugene Berdnikov
Re: вопрос по .xsession-errors
On 2015-11-23, Melleus wrote: > 1. имеем файл ~/.xsession-errors > > 2. в него кто-то раз в несколько секунд с завидным постоянством пишет > следующее: > > sh: 1: iwconfig: not found > > Обнаружил случайно, решил заглянуть, почему такой большой размер у > файла. А там - это. > > Вопрос - как разобраться, что происходит? $ sudo apt-get install auditd $ sudo auditctl -w ~/.xsession-errors -p w Ждать и затем анализировать /var/log/audit/audit.log, или: $ sudo ausearch -f ~/.xsession-errors В конце: $ sudo auditctl -W ~/.xsession-errors $ sudo service auditd stop $ sudo update-rc.d auditd disable Я попробовал: $ sudo auditctl -w /tmp -p w При старте xterm в логе есть строчка: type=SYSCALL msg=audit(1448308853.684:34): arch=c03e syscall=87 success=yes exit=0 a0=24218a0 a1=7ffe55d12880 a2=7ffe55d12880 a3=7ffe55d12640 items=2 ppid=3522 pid=12342 auid=4294967295 uid=1000 gid=1000 euid=1000 suid=1000 fsuid=1000 egid=1000 sgid=1000 fsgid=1000 tty=(none) ses=4294967295 comm="xterm" exe="/usr/bin/xterm" key=(null) Тут у нас pid, ppid, uid, gid, а также: comm="xterm" exe="/usr/bin/xterm" что очень удобно для быстро исчезающих скриптов. > Извиняюсь за шум, методом исключения выяснил, что это awesome > виноват. Я полагаю таким способом Вы бы прямо получили ответ без "метода исключения". Чесно говоря до Вашего поста я о auditctl ничего не знал, но недавно отлаживал CLASSPATH в Tomcat и там оказалось классным: $ inotifywait -m -r /tmp Но inotify не рассказывает какие pid задействованы. inotify можно узнать какие файлы трогают, но этого не достаточно в Вашем случае. Для себя поискал как решается задача, что б знать на будущее, auditd - дополнительно говорит кто трогает. Там еще есть какие то штуки: https://en.wikipedia.org/wiki/File_Alteration_Monitor -- Best regards!
Re: systemd
On 2015-11-22, Artem Chuprina wrote: > OG> * 1 TCP соединение, вместо нескольких. Избегаем задержет на TCP > рукопожатие, > OG>не знаю, может есть также плюс и для SSL/TLS. Итого страничики через > OG>мобильное GPRS будут заметно быстрее открываться. > > По сравнению с чем он дает преимущество? С HTTP/1.1, в котором это > ввели, и который все давно уже умеют? Таки да: https://tools.ietf.org/html/rfc7230 Хотя 6. Connection Management HTTP messaging is independent of the underlying transport- or session-layer connection protocol(s). все же: HTTP implementations are expected to engage in connection management, which includes maintaining the state of current connections, establishing a new connection or reusing an existing connection, processing messages received on a connection, detecting connection failures, and closing each connection. Most clients maintain multiple connections in parallel, including more than one connection per server endpoint. Most servers are designed to maintain thousands of concurrent connections, while controlling request queues to enable fair use and detect denial-of-service attacks. Это если говорить о количестве соединений к одному серверу. А то я забыл точный текст книги по поводу ограничения на 2 соединения к 1 хосту, и со стандартом не сверялся, в книге так: http://http2-explained.haxx.se/content/en/part3.html#34-sharding Initially the HTTP 1.1 specification stated that a client was allowed to use maximum of two TCP connections for each host. So, in order to not violate the spec clever sites simply invented new host names and – voilá - you could get more connections to your site and decreased page load times. Over time, that limitation was removed and today clients easily use 6-8 connections per host name but they still have a limit so sites continue to use this technique to bump the number of connections. Recent stats from httparchive.org show that the top 300K URLs in the world need on average 40(!) TCP connections to display the site, and the trend says this is still increasing slowly over time. Если же речь о HTTP pipelining - то я об этом ничего не знаю, кроме того что никто из массовых WEB клиентов не использует эту возможность. Попробовал открыть сайт с высокоскоростным соединением, Firefox Web Developer показал: 5'400 ms на connection 40 ms на waiting последующие страницы имели: 0 ms на connection На GPRS соединении у меня connection занимало 5-20 сек и каждое живое TCP соединение делало связь очень напряжной, вплоть до того что браузер отказывался загружать ресурсы по таймауту (это когда рядом открыты вкладки с Ajax долбилками, которые так любят встраивать в комерческие сайты). В общем влияние числа соединений на качество/скорость WEB есть, особенно для мобильной связи (сейчас в сети - подавляющее большинство клиентов - мобильны). Я не нахожу сравнения экспертов - как HTTP 2 на практике решает проблемы. К сожалению на https://www.ietf.org не смог найти информацию о рабочем комитете по HTTP 2 и их целях. Есть теория что WebSocket лучше ложатся в HTTP 2: http://stackoverflow.com/questions/28582935/does-http-2-make-websockets-obsolete https://bloggeek.me/websockets-http2/ Эта штука нужна социалкам, общалкам. -- Best regards!
Re: Как работает локальный DNS кеш?
On 2015-11-23, Eugene Berdnikov wrote: >> которые считывает GLib. Как я понял GLib также умеет общаться с DNS серверами >> (так как это делает dig, есть ощущение что nslookup использует >> getaddrinfo(3)). > > В "ltrace nslookup localhost |& fgrep addr" ничего не ловится, > значит, getaddrinfo(3) там не используется. Было бы странно для > писателей bind9 использовать такие вызовы, ибо их модули > извлекают из пакетов гораздо больше информации, которую через > API для getaddrinfo получить никак невозможно. С другой стороны, > от gethostbyname/getaddrinfo невозможно оторвать просмотр hosts > и прочей описанной в nsswitch.conf хни, а dig/nslookup делают > исключительно обращения к dns, и ничего более. Поэтому nslookup > просто не может работать через getaddrinfo(3). > Ясно, я забыл что nslookup из проекта BIND. >> У меня только сомнения по поводу наличия кода в GLibc работающего с DNS >> серверами на подобии как это делает dig. > > В чём подобие-то? В glibc есть лишь резолвер, а dig имеет гораздо более > широкий функционал. Я не знал в том что glibc содержит частичную реализацию протокола (как Вы сказали резолвер): https://www.ietf.org/rfc/rfc1035.txt Было удивительно что glibc не просто прослойка к ядру, но также выполняет прикладные сервисы как разрешение имен. Я наивно полагал что этим занимается ядро или сторонняя служба... -- Best regards!
Re: Как работает локальный DNS кеш?
On Mon, Nov 23, 2015 at 08:13:12PM +0200, Oleksandr Gavenko wrote: > В общем прояснилось, еще почитал: > > GETADDRINFO(3) > `info libc "Name Service Switch"' > http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html > > Итого getaddrinfo(3), gethostbyname(3) встроены в GLib. Не в Glib, а в glibc. Под "glib" обычно понимают прикладную библиотеку Гнома, а glibc есть базовая библиотека всего линуксового рантайма, включающая интерфейсы к вызовам ядра. > которые считывает GLib. Как я понял GLib также умеет общаться с DNS серверами > (так как это делает dig, есть ощущение что nslookup использует > getaddrinfo(3)). В "ltrace nslookup localhost |& fgrep addr" ничего не ловится, значит, getaddrinfo(3) там не используется. Было бы странно для писателей bind9 использовать такие вызовы, ибо их модули извлекают из пакетов гораздо больше информации, которую через API для getaddrinfo получить никак невозможно. С другой стороны, от gethostbyname/getaddrinfo невозможно оторвать просмотр hosts и прочей описанной в nsswitch.conf хни, а dig/nslookup делают исключительно обращения к dns, и ничего более. Поэтому nslookup просто не может работать через getaddrinfo(3). > У меня только сомнения по поводу наличия кода в GLibc работающего с DNS > серверами на подобии как это делает dig. В чём подобие-то? В glibc есть лишь резолвер, а dig имеет гораздо более широкий функционал. -- Eugene Berdnikov
Re: Как работает локальный DNS кеш?
On 2015-11-22, Artem Chuprina wrote: > resolvconf у меня живет весьма неплохо, но я не пользуюсь connman/nm. > Пользуюсь wicd, и про него знаю, что он сам эту информацию не трогает, > ею занимается dhclient (или кто там у тебя работает с DHCP) в связке с > resolvconf. > > И кэшем работает dnsmasq. На домашнем сервере - bind9, и ему приходится > вручную добавлять скрипт, звездочка в документации неспроста. А с > dnsmasq работает из коробки. В общем прояснилось, еще почитал: GETADDRINFO(3) `info libc "Name Service Switch"' http://www.tldp.org/LDP/nag2/x-087-2-resolv.library.html Итого getaddrinfo(3), gethostbyname(3) встроены в GLib. Есть ряд файлов настроек: /etc/host.conf /etc/hosts /etc/resolv.conf /etc/nsswitch.conf которые считывает GLib. Как я понял GLib также умеет общаться с DNS серверами (так как это делает dig, есть ощущение что nslookup использует getaddrinfo(3)). Кеширование DNS запросов может быть сделано либо в GLib, либо в приложении, либо прописыванием localhost в /etc/resolv.conf и поднятием локального DNS сервера кеша. dhclient по успешному выполнению вызывает тригеры, пример доступной информации в дригере в файле: /etc/dhcp/dhclient-enter-hooks.d/debug for prefix in '' 'cur_' 'new_' 'old_'; do for basevar in reason interface medium alias_ip_address \ ... domain_name domain_search domain_name_servers \ ... dhcp6_domain_search dhcp6_name_servers ; do var="${prefix}${basevar}" eval "content=\$$var" echo "$var='${content}'" >> /tmp/dhclient-script.debug resolvconf поставляет свой хук /etc/dhcp/dhclient-enter-hooks.d/resolvconf и затем сообщает кеширующему DNS серверу о новых настройках. У меня только сомнения по поводу наличия кода в GLibc работающего с DNS серверами на подобии как это делает dig. -- Best regards!
Re: вопрос по .xsession-errors
Eugene Berdnikov writes: > On Mon, Nov 23, 2015 at 02:18:26PM +0200, Melleus wrote: >> Прошу подсказки в такой ситуации: >> >> 1. имеем файл ~/.xsession-errors >> >> 2. в него кто-то раз в несколько секунд с завидным постоянством пишет >> следующее: >> >> sh: 1: iwconfig: not found >> >> 3. с сетью (и вообще с системой в целом) видимых проблем нет, все >> работает. >> >> Обнаружил случайно, решил заглянуть, почему такой большой размер у >> файла. А там - это. >> >> Вопрос - как разобраться, что происходит? > > Проще всего сделать исполняемый файлик iwconfig с командочкой вроде > ps auxfww | mail -s iwconfig root > Можете подставить свой e-mail по вкусу. Есть и другие решения. Все гениальное - просто. И тот, кто дернет за ниточку, спалит себя сам :) Спасибо за идею!
Re: вопрос по .xsession-errors
On Mon, Nov 23, 2015 at 02:18:26PM +0200, Melleus wrote: > Прошу подсказки в такой ситуации: > > 1. имеем файл ~/.xsession-errors > > 2. в него кто-то раз в несколько секунд с завидным постоянством пишет > следующее: > > sh: 1: iwconfig: not found > > 3. с сетью (и вообще с системой в целом) видимых проблем нет, все > работает. > > Обнаружил случайно, решил заглянуть, почему такой большой размер у > файла. А там - это. > > Вопрос - как разобраться, что происходит? Проще всего сделать исполняемый файлик iwconfig с командочкой вроде ps auxfww | mail -s iwconfig root Можете подставить свой e-mail по вкусу. Есть и другие решения. -- Eugene Berdnikov
Re: вопрос по .xsession-errors
Извиняюсь за шум, методом исключения выяснил, что это awesome виноват.
вопрос по .xsession-errors
Прошу подсказки в такой ситуации: 1. имеем файл ~/.xsession-errors 2. в него кто-то раз в несколько секунд с завидным постоянством пишет следующее: sh: 1: iwconfig: not found 3. с сетью (и вообще с системой в целом) видимых проблем нет, все работает. Обнаружил случайно, решил заглянуть, почему такой большой размер у файла. А там - это. Вопрос - как разобраться, что происходит? Спасибо заранее. ЗЫ. Комп используется как декстоп (писательство, я не настоящий айтишник). Сижу на стабильной ветке, десктопом awesome заведует, сетью - network manager.
Re: создание репозитория (вопрос по файлу Contents-amd64.gz)
On Mon, 23 Nov 2015 12:53:36 +0300 Andrew Kirsanov wrote: > У меня есть репозиторий на двух дисках (ОС Астра линукс - debian > based). > > Хочу соединить их в один репозиторий, чтобы разместить в сети. 1. По-моему, проще оставить это двумя разными репозиториями и прописать в sources.list на тех машинах, которые будут этими репозиториями пользоваться, две строчки. Тогда можно раздавать репозитории прямо с примонтирвоанных образов дистрибутивных дисков > > Делаю так. > Собрал два пула с разных дисков в одно место. > Файлы в папке dists генерю самостоятельно командой apt-ftparchive. 2. Можно взять какой-нибудь другой инструмент, генерирующий Packages и Contents, но умеющий pool-based репозитории, например reprepro. > Но на выходе у меня получается список без относительны
создание репозитория (вопрос по файлу Contents-amd64.gz)
У меня есть репозиторий на двух дисках (ОС Астра линукс - debian based). Хочу соединить их в один репозиторий, чтобы разместить в сети. Делаю так. Собрал два пула с разных дисков в одно место. Файлы в папке dists генерю самостоятельно командой apt-ftparchive. Но на выходе у меня получается список без относительных путей. Например: В оригинальном файле Contents-amd64.gz *etc/ald/ald.confnon-free/admin/ald-client* У меня получается просто имя etc/ald/ald.conf ald-client Как сделать аналогичный список? А может я вообще не так все делаю? -- Andrew Kirsanov