Re: ifupdown / systemd
Tim Sattarov writes: > On 12/01/16 01:23 PM, Max Dmitrichenko wrote: >> Между тем, проблема не столько в systemd, сколько в пакете ifupdown, >> который явственно декларирует конфликт с новой версией systemd, и в fix: со *старой* версией systemd >> суровой правде жизни о том, что заливаются в testing они не синхронно. >> То есть пинять (а точнее пытаться пинять) нужно тогда уж целиком на >> весь Debian, что они такие растакие держут в тестинге конфликтующие >> версии, а бюрократия не даёт им сделать это синхроно. Уверен, что >> такой ситуации не возникнет при апгрейде на strech, когда он станет >> stable. А в остальном всё верно. > Что интересно, по моему никто так и не понял, в чем дело то с ifupdown > vs. systemd Разве? > читаем: > > при апгрейде > ifupdown : Breaks: systemd (< 228-3~) but 228-2+b1 is installed. > > то есть ему нужна версия *новее* Правильно. Новая несовместимая версия ifupdown прилетела раньше, чем нужная ей версия systemd. > Нужно подождать пока в тестинг придет systemd версии 228-4 (текущая > версия в сиде) или новее и все разрешится. Не обязательно. Можно ещё: а) временно поставить на удержание старую версию ifupdown, и б) поставить systemd из sid. signature.asc Description: PGP signature
Re: ifupdown / systemd
On 12/01/16 01:23 PM, Max Dmitrichenko wrote: > Между тем, проблема не столько в systemd, сколько в пакете ifupdown, > который явственно декларирует конфликт с новой версией systemd, и в > суровой правде жизни о том, что заливаются в testing они не синхронно. > То есть пинять (а точнее пытаться пинять) нужно тогда уж целиком на > весь Debian, что они такие растакие держут в тестинге конфликтующие > версии, а бюрократия не даёт им сделать это синхроно. Уверен, что > такой ситуации не возникнет при апгрейде на strech, когда он станет > stable. Что интересно, по моему никто так и не понял, в чем дело то с ifupdown vs. systemd читаем: при апгрейде ifupdown : Breaks: systemd (< 228-3~) but 228-2+b1 is installed. то есть ему нужна версия *новее* http://metadata.ftp-master.debian.org/changelogs/main/s/systemd/systemd_228-4_changelog systemd (228-3) unstable; urgency=medium * Eliminate "hotplug.functions" udev helper and put the logging functions directly into net.agent. This simplifies the migration of the latter to ifupdown. * Drop net.agent, 80-networking.rules, and ifup@.service. These moved to ifupdown 0.8.5 now. Add Breaks: to earlier versions. * Drop networking.service.d/systemd.conf. The ifupdown package now ships a proper service file so this drop-in file is no longer necessary. http://metadata.ftp-master.debian.org/changelogs/main/i/ifupdown/ifupdown_0.8.8_changelog ifupdown (0.8.5) unstable; urgency=medium * Move ifupdown related files from the systemd and udev packages to this package. Closes: #809171 Нужно подождать пока в тестинг придет systemd версии 228-4 (текущая версия в сиде) или новее и все разрешится.
Re: ifupdown / systemd
On 2016-01-12, Victor Wagner wrote: > Лично мне вообще не слишком понятно зачем ускорять время загрузки. > Загрузка происходит раз в несколько месяцев, при апгрейде ядра, и при > этом все равно через раз fsck запускается. Но если уж делать > dependency-based порядок выполнения, зачем вместо того чтобы брать > стандартный и все равно присутствующий в дистрибутиве инструмент, > изобретать велосипед с квадратными колесами. Официальный ответ от месии: http://0pointer.de/blog/projects/the-biggest-myths.html 3 Myth: systemd's fast boot-up is irrelevant for servers. That is just completely not true. Many administrators actually are keen on reduced downtimes during maintenance windows. In High Availability setups it's kinda nice if the failed machine comes back up really fast. In cloud setups with a large number of VMs or containers the price of slow boots multiplies with the number of instances. Spending minutes of CPU and IO on really slow boots of hundreds of VMs or containers reduces your system's density drastically, heck, it even costs you more energy. Slow boots can be quite financially expensive. Then, fast booting of containers allows you to implement a logic such as socket activated containers, allowing you to drastically increase the density of your cloud system. Of course, in many server setups boot-up is indeed irrelevant, but systemd is supposed to cover the whole range. And yes, I am aware that often it is the server firmware that costs the most time at boot-up, and the OS anyways fast compared to that, but well, systemd is still supposed to cover the whole range (see above...), and no, not all servers have such bad firmware, and certainly not VMs and containers, which are servers of a kind, too. Что такое socket activated containers? Еще мне не ясно что может тупить при загрузке в VDS / облаке? Тенденция то какая - один контейнер - один сервис. Значит убираем все нафик. Остается статический /etc/network/interfaces, мониторилка, sshd и основной сервис (mysqld, httpd, ...). Вот я хостю бложик: bash# sudo pstree init─┬─acpid ├─cron ├─6*[getty] ├─lighttpd ├─rsyslogd─┬─{in:imklog} │ ├─{in:imuxsock} │ └─{rs:main Q:Reg} ├─sshd───sshd───sshd───bash───sudo───pstree ├─udevd └─xinetd Расскажите мне зачем устанавливать: * logind * dbus * systemd * consolekit Кстати удалить udevd - нельзя, от него зависит ядро )) Еще не ясно зачем держать в KVM госте acpid - безопасно ли его будет удалить? Перезагрузку с удаленным acpid хост пережил... И зачем getty для VDS? При апгрейде с wheezy приползли dbus, systemd и irqbalance. Их удалил. -- http://defun.work/
Re: ifupdown / systemd
On Wed, Jan 13, 2016 at 06:05:43PM +0200, Oleksandr Gavenko wrote: >Arch Linux probably did it the quickest way. You know, distributions >attract different kinds of people, of course. If you looked at Arch Linux, >it attracted very progressive kinds of people – like power users. А моя думал, школие... >There are also developers from Debian – two or three of them. > > Не они ли голосовали втихаря за Systemd )) В Дебиан ~2к разработчиков с правом голоса. Только два голоса погоды б не сделали.
Re: ifupdown / systemd
On 2016-01-13, Sergey B Kirpichev wrote: > On Wed, Jan 13, 2016 at 02:51:54PM +0200, Oleksandr Gavenko wrote: >> On 2016-01-12, Sergey B Kirpichev wrote: >> > Что вы предлагали в качестве решения проблем sysvinit? >> >> У sysvinit есть проблемы?? > > Да, конечно. Я же уже приводил в качестве примера ужос > с управлением сервисами /etc/init.d/foo start/stop. > Раньше считалось что init скрипт плохо написан если не прибивал детишек на stop. Давайте посмотрим на http://www.netzmafia.de/skripten/unix/linux-daemon-howto.html Linux Daemon Writing HOWTO, 2004 4. Basic Daemon Structure Fork off the parent process Change file mode mask (umask) Open any logs for writing Create a unique Session ID (SID) Change the current working directory to a safe place Close standard file descriptors Enter actual daemon code Парадигма сменилась - теперь systemd валит детишек через cgroup. Т.е. отменяют шаг: Create a unique Session ID (SID) Спору нет - я за то что бы компьютер делал работу за меня. Т.е. должны появиться новые требования к написанию демонов: http://www.freedesktop.org/software/systemd/man/daemon.html Ранее init-скритп знал как остановить демон, теперь появились требования: If SIGTERM is received, shut down the daemon and exit cleanly. If SIGHUP is received, reload the configuration files, if this applies. Звучит отлично и мне нравятся эти соглашения! Есть ощущение что монструозние сервисы, типа Oracle Database не перейдут на systemd approach, вот как происходит старт/остановка: $ sqlplus / as sysdba SQL> STARTUP SQL> SHUTDOWN IMMEDIATE https://docs.oracle.com/cd/E17781_01/server.112/e18804/startup.htm Кстати подскажите кто нибудь - активация через сокет: If your daemon provides services to other local processes or remote clients via a socket, it should be made socket-activatable following the scheme pointed out below. Like D-Bus activation, this enables on-demand starting of services as well as it allows improved parallelization of service start-up. Also, for state-less protocols (such as syslog, DNS), a daemon implementing socket-based activation can be restarted without losing a single request. Это не то же самое что и inetd? Или в systemd есть возможность прописать статическую и другие зависимости для сервиса с сокет-активацией? Например не отвечать через сокет пока сервис времени не обновил локальное время? Такие завичимости мне кажутся прогресом (если они работают). >> Года 2 назад systemd пропихивали с мантрой - паралельная загрузка, будем >> грузиться быстрей. > > За этими обсуждениями я не следил достаточно, чтобы утверждать, > что вы врете, но склонен полагать что это именно так. Как минимум, Действительно, не совсем так. Про скорость хвастался Потеринг в 2013: http://freedesktop.org/wiki/Software/systemd/Optimizations/ замечая что: http://0pointer.de/blog/projects/the-biggest-myths.html Yes, systemd is fast (A pretty complete userspace boot-up in ~900ms, anyone?), but that's primarily just a side-effect of doing things **right**. Свежее интервью (2015): https://www.linuxvoice.com/interview-lennart-poettering/ говорит интересные вещи: * The Upstart way is always, “if this is started, then start that”. If the network is up, you take that as a trigger to start NFS and things like that. It always has this effect that you start as much as possible instead of as little as possible. ...we came to the conclusion that Upstart is conceptually wrong... Запускать что то только по необходимости - класно! Такое sysvinit не умеет. Для этого inetd? * So we started writing Systemd, and Red Hat didn’t like it at all. Red Hat management said: no, we’re going for Upstart, don’t work on that. So I said, OK, I’ll work on it in my free time. Eventually Red Hat realised that the problems we solved with Systemd were relevant, and were problems that needed to be solved, and that you couldn’t ignore them. А тут забыл сказать что менеджеры увидели svhost.exe и возможность диктовать условия рынку. Изветная стратения Mictosoft - вываливать раз в пятилетку новое API, пока конкуренты адаптируют продукты они продают. Только RH дополнительно к этому еще сможет продавать услуги по портированию и консалтинг )) * Debian had its init scripts, and Fedora had its init scripts, and they all kind of did the same thing, and did it differently, and some are better, and some are worse. We thought OK: this is bullshit, let’s write this in C in a unified way, and try to pick the best features of all distributions and make a convincing argument that it’s the right way. Классно! Только снова ситуация как когда LSB описывал RPM и забыл про DEB )) * Why do you think some distributions managed to adopt Systemd without any major fights, and then others like Debian had very intense debates and resignations? Arch Linux probably did it the quickest way. You know, distributions attract diff
Re: ifupdown / systemd
В Tue, 12 Jan 2016 17:43:39 +0300 Victor Wagner пишет: > Лично мне вообще не слишком понятно зачем ускорять время загрузки. > Загрузка происходит раз в несколько месяцев, при апгрейде ядра, и при > этом все равно через раз fsck запускается. Не десктопом и сервером единым, однако. Как по мне, почти любое решение должно иметь право на существование (в debian), кроме тех, у которых нет или сильно осложнена возможность отладки с целью локализации проблемы или поиска решений задачи. И таким я считаю systemd.
Re: ifupdown / systemd
On 12/01/16 09:43 AM, Victor Wagner wrote: > Лично мне вообще не слишком понятно зачем ускорять время загрузки. > Загрузка происходит раз в несколько месяцев, при апгрейде ядра, и при > этом все равно через раз fsck запускается. Но если уж делать > dependency-based порядок выполнения, зачем вместо того чтобы брать > стандартный и все равно присутствующий в дистрибутиве инструмент, > изобретать велосипед с квадратными колесами. Я бы поспорил насчет этого. есть много проектов, особенно связанных с облачными деплойментами, где нужна быстрая загрузка. в том же AWS, есть Scaling group, который реагирует на нагрузку на сервис и запускает/останавливает дополнительные сервера. пауза в 30 секунд (какая есть сейчас в стандартном ядре, на Xen железе) уже существенна для своевременной реакции.
Re: ifupdown / systemd
On Wed, 13 Jan 2016 16:01:16 +0300 Artem Chuprina wrote: > > А типичный пакет, это, например apt, bash, modutils, sudo. > > Вот я не админ хостинга. Мне удобнее донастраивать скриптами dnsmasq > через .d. Руками я в его конфиг хожу раз в полгода, а скриптами — > трижды в день. dnsmasq - это пример пакета который более-менее выдерживает такое обращение. С ним редко возникает проблема "найти где лежит та настройка, которая оверрайдит то, что я сейчас туда вписал". Опять же, у него по умолчанию /etc/dnsmasq.d пустая. А у того же dovecot-а поди еще найди куда правильно положить настройку.
Re: ifupdown / systemd
On Wed, Jan 13, 2016 at 04:01:16PM +0300, Artem Chuprina wrote: > > А типичный пакет, это, например apt, bash, modutils, sudo. > > Вот я не админ хостинга. Мне удобнее донастраивать скриптами dnsmasq через > .d. Руками я в его конфиг хожу раз в полгода, а скриптами — трижды в день. Тут речь не о том, как удобнее, а о том - как оно на практике в Debian устроено. Похоже, человек элементарно не в теме, что данная схема используется практически в каждом пакете Debian, в т.ч. для конфигурации apt, bash и sudo. А про удобство тоже писали - дело и не в нем, а в том что никаких мифических проблем с поиском что, куда и в какой последовательности подключается - в данной схеме нет.
Re: ifupdown / systemd
On Wed, Jan 13, 2016 at 02:51:54PM +0200, Oleksandr Gavenko wrote: > On 2016-01-12, Sergey B Kirpichev wrote: > > Что вы предлагали в качестве решения проблем sysvinit? > > У sysvinit есть проблемы?? Да, конечно. Я же уже приводил в качестве примера ужос с управлением сервисами /etc/init.d/foo start/stop. > Года 2 назад systemd пропихивали с мантрой - паралельная загрузка, будем > грузиться быстрей. За этими обсуждениями я не следил достаточно, чтобы утверждать, что вы врете, но склонен полагать что это именно так. Как минимум, в качестве причин для использования LSB-зависимостей - обычно приводят совсем другие. См. например wiki: https://wiki.debian.org/LSBInitScripts/DependencyBasedBoot
Re: ifupdown / systemd
Victor Wagner writes: >> > А когда конфиг собирается из >> > кучи файлов, да еще указанные в них параметры оверрайдят друг друга >> > в не совсем очевидной последовательности >> >> Можно пример такой неочевидности? Больше похоже на страшилку - для >> типичного пакета (напр. apache2 или nginx) - последовательность > > Ну точно сисадмин хостинга. Web-сервер - это нетипичный пакет. Как > правило, на рабочей станции его нет. > > Уж скорее там dovecot будет. > > А типичный пакет, это, например apt, bash, modutils, sudo. Вот я не админ хостинга. Мне удобнее донастраивать скриптами dnsmasq через .d. Руками я в его конфиг хожу раз в полгода, а скриптами — трижды в день.
Re: ifupdown / systemd
On 2016-01-12, Sergey B Kirpichev wrote: > Что вы предлагали в качестве решения проблем sysvinit? У sysvinit есть проблемы?? Года 2 назад systemd пропихивали с мантрой - паралельная загрузка, будем грузиться быстрей. Это не сработало, startpar(8) и немного шаманства в заголовках решили проблему долгой загрузки. У меня десктоп стартует до xterm за 3-4 сек (с SSD). Выдумывать шину, через которую разрешать зависимости скриптов загрузки? Может не актуально? Кстати лагерь systemd терпит неудачи в ядре. И даже с навязываемым сторонним модулем (раз в ядро не удалось пропихнуть): https://lists.fedoraproject.org/pipermail/devel/2015-October/216235.html kdbus module being removed from Rawhide И причиной почему выкинули - техническое несовершенство kdbus, признаное самими инжинерами. Зато в какой спешке и горячке впихивают! Просто бизнес, ничего личного )) -- http://defun.work/
Re: ifupdown / systemd
13 января 2016 г., 14:04 пользователь Andrey Melnikoff написал: > Ага-ага. Я во всем этом одного не понимаю - для чего это геройство тянуть > древнюю версию годами? Нет, есть две версии печали - билиотеки с ABI+soname, > и новые версии софта которые портированны на библиотеки которых нет в $stable. По-моему, вы подошли вплотную к той точке, когда надо сделать свой дистрибутив ) -- With best regards Max Dmitrichenko
Re: перемещение на другое Рабочее место в xfce
13.01.2016 00:33, sergio пишет: > Вдруг > browser.tabs.loadDivertedInBackground=true > поможет? > нет, это не помогло... помог совет от Михаила: Настройки \ Диспетчер окон (дополнительно) \ Фокус \ Когда окно активизируется выбрал "Ничего не делать". -- BW, Сохин Вячеслав
Re: ifupdown / systemd
Max Dmitrichenko wrote: > 13 января 2016 г., 11:01 пользователь Andrey Melnikoff > написал: > > Max Dmitrichenko wrote: > >> Производитель софтины фиксит у себя апстрим. С хорошей вероятностью > >> патч, который фиксит проблему, подойдет к той версии пакета, которая в > >> stable или в oldstable. Но может быть и так, что: > >> 1) Патч не подходит (не накладывается) > > С чего бы это? > Так бывает. Контекст патча может отличаться между upstream и соотв. > местом в исходниках старой версии. > >> 2) Софтина давно не поддерживается разработчикам > > Выкинуть и собрать свежую, поддерживаемую. > Нихрена. Политика debian не разрешает обновлять версии пакетов в > stable. За исключением volatile, куда кладутся браузеры и ещё что-то Пальцем покажи где она запрещает. Я только вижу, что она разрешает обновзять пакажд если фиксить овер-дохрена надо. > типа антивирусов, кажется. К этому пришли именно потому, что > затрахались портировать фиксы проблем безопасности, коих в браузерах > чуть больше чем до хрена, из апстрима в версию stable и oldstable. Во-во, опять вернулись к проблеме с тухлыми пакаджами и их поддержкой. > >> > А вот возьмем другой CVE-2015-8668 на libtiff5 - во, тут думать надо, > >> > апстрим не разродился патчем - поэтому и починим как разродиться. > > > >> И если не разродится, то так и забьют? ) > > Таки да. Багов вида "не работает" в трекере - вагон, и на большенство - > > забито с прибором. > Ещё раз. Мы сейчас говорим о проблемах с security и только о них. > Багов вида "у меня не работает", "у меня глючит", "у меня падает", > действительно дохрена. Но вот security-баги устраняются всегда и > достаточно быстро, если речь про stable. Ага-ага. Я во всем этом одного не понимаю - для чего это геройство тянуть древнюю версию годами? Нет, есть две версии печали - билиотеки с ABI+soname, и новые версии софта которые портированны на библиотеки которых нет в $stable.
Re: перемещение на другое Рабочее место в xfce
12.01.2016 20:54, Sohin Vyacheslav пишет: > 12.01.2016 17:35, Mikhail A Antonov пишет: >> 12.01.2016 17:50, Sohin Vyacheslav пишет: >> Настройки \ Диспетчер окон (дополнительно) \ Фокус \ Когда окно >> активизируется выбери "Ничего не делать". >> > Спасибо, Михаил, всё зашуршало... а то бесило это постоянно)) Рад что помогло. И отвечать стоит в рассылку, а не мне. Удачи. -- Best regards, Mikhail - WWW: http://www.antmix.ru/ XMPP: ant...@stopicq.ru signature.asc Description: OpenPGP digital signature
Re: ifupdown / systemd
On 13/01/16 11:59, sergio wrote: > Да я не про этот конкретный патч, а про сорцы в целом. И впечатление > такое, что openvpn сам не может решить чего хочет. openvpn-2.3.10 % grep conf distro/systemd/openvpn-client@.service ExecStart=/usr/sbin/openvpn --cd /etc/openvpn/client --config %i.conf --daemon --writepid /var/run/openvpn/client_%i.pid openvpn-2.3.10 % grep conf distro/rpm/openvpn.init.d.suse ... for c in `/bin/ls *.conf 2>/dev/null`; do -- sergio
Re: reboot & dbus
On 13/01/16 12:29, Max Dmitrichenko wrote: > Надо дергуть соотв. метод у сервиса logind (который нынче тоже часть > systemd). У меня нет systemd. -- sergio
Re: reboot & dbus
Надо дергуть соотв. метод у сервиса logind (который нынче тоже часть systemd). У интерфейса systemd он тоже есть, но только для рута. http://www.freedesktop.org/wiki/Software/systemd/logind/ И, по-моему, logind разрешит тебе это сделать, если сочтет твою сессию локальной. 13 января 2016 г., 1:29 пользователь sergio написал: > On 13/01/16 01:23, sergio wrote: > > >> Жмёшь ты аппаратную кнопку ресет или пишешь reboot --- в данном случае >> не важно. > > > Кстати про dbus: а как с консоли нажать reset или power точно так же как > из иксовой сессии? Можно, наверное, посмотреть как это сделано для > выключения по acpi по дефолту, но вдруг кто уже в курсе? > > > -- > sergio > -- With best regards Max Dmitrichenko
Re: ifupdown / systemd
On 13/01/16 11:25, Victor Wagner wrote: > Это очень новый патч. Openvpn 2.3. В Debian эта инфраструктура, > насколько я помню, была уже во времена openvpn 2.1. То есть скторее, > этот патч был по мотивам дебиансовсокго законтрибучен в апстрим. Да я не про этот конкретный патч, а про сорцы в целом. И впечатление такое, что openvpn сам не может решить чего хочет. openvpn-2.3.10 % ls sample/sample-windows sample.ovpn* openvpn-2.3.10 % ls sample/sample-config-files client.conf loopback-server README tls-home.conf firewall.sh* office.up*server.conf tls-office.conf -- sergio
Re: ifupdown / systemd
13 января 2016 г., 11:01 пользователь Andrey Melnikoff написал: > Max Dmitrichenko wrote: >> Производитель софтины фиксит у себя апстрим. С хорошей вероятностью >> патч, который фиксит проблему, подойдет к той версии пакета, которая в >> stable или в oldstable. Но может быть и так, что: >> 1) Патч не подходит (не накладывается) > С чего бы это? Так бывает. Контекст патча может отличаться между upstream и соотв. местом в исходниках старой версии. >> 2) Софтина давно не поддерживается разработчикам > Выкинуть и собрать свежую, поддерживаемую. Нихрена. Политика debian не разрешает обновлять версии пакетов в stable. За исключением volatile, куда кладутся браузеры и ещё что-то типа антивирусов, кажется. К этому пришли именно потому, что затрахались портировать фиксы проблем безопасности, коих в браузерах чуть больше чем до хрена, из апстрима в версию stable и oldstable. >> > А вот возьмем другой CVE-2015-8668 на libtiff5 - во, тут думать надо, >> > апстрим не разродился патчем - поэтому и починим как разродиться. > >> И если не разродится, то так и забьют? ) > Таки да. Багов вида "не работает" в трекере - вагон, и на большенство - > забито с прибором. Ещё раз. Мы сейчас говорим о проблемах с security и только о них. Багов вида "у меня не работает", "у меня глючит", "у меня падает", действительно дохрена. Но вот security-баги устраняются всегда и достаточно быстро, если речь про stable. Ну и в качестве дополнительного свидетельства того, что мейнтейнер имеет (и использует) творческую возможность в приготовлении патчей с отсебятиной, нельзя не вспомнить багу, которую мейнтейнеры внесли в Debian в генератор случайных чисел, из-за чего ключи генерились очень ограниченные. -- With best regards Max Dmitrichenko
Re: ifupdown / systemd
On Wed, 13 Jan 2016 10:44:49 +0300 sergio wrote: > On 13/01/16 07:14, Victor Wagner wrote: > > > Самому openvpn глубоко пофиг, как называется то, что указали в опции > > --config. Что указали, то и читает. > > Конечно. > > > > Назвать его .conf - дебиановское решение. > > Нет. > > openvpn-2.3.10 % grep conf contrib/multilevel-init.patch > # Start every .conf in $work and run .sh if exists > - for c in `/bin/ls *.conf */*.conf 2>/dev/null`; do > + for c in `find * -name "*.conf" 2>/dev/null`; do > bn=${c%%.conf} > Это очень новый патч. Openvpn 2.3. В Debian эта инфраструктура, насколько я помню, была уже во времена openvpn 2.1. То есть скторее, этот патч был по мотивам дебиансовсокго законтрибучен в апстрим. --
Re: ifupdown / systemd
Max Dmitrichenko wrote: > 12 января 2016 г., 17:56 пользователь Andrey Melnikoff > написал: > > Max Dmitrichenko wrote: > > А кто спонсирует разработку этого очень-нужного софта в виде gnome, NM, > > pulseaudio, systemd друг на друга завязанного? Добрый дядя Шаттлворт? > А как, простите, systemd или NM завязан на gnome или pulseaudio? Вы > ещё gstreamer забыли. gnome без systemd уже не работает. NM в отрыве от gnome нах не нужен. Он то и с ним не сильно нужен из-за тупости в подходе "всё надо конфигурить через меня". Особенно доставляют нерабочие VPN-модули без сообщений в GUI. > А то, что, например, все они (на счёт pulseaudio не знаю точно) > используют dbus - это даже хорошо. Много лучше, чем если бы каждая из > этих систем исползовала свой уникальный способ, для управления ею. Да нету в этом ничего хорошего. Появляется единая точка отказа, с хреновыми возможностями отладки. А в цвете sd_notify() & co - systemd plague меделенно и верно расползается по всему софту который хоть как-то умеет работать демоном.
Re: ifupdown / systemd
Max Dmitrichenko wrote: > 13 января 2016 г., 0:53 пользователь Andrey Melnikoff > написал: > > Еще раз, читаем медленно - патчи беруться от производителя софтины, ибо CVE > > - на софтину, репортиться производителю и ожидает его реакции в виде патчей, > > новых версий, "а вы так не делайте". > Производитель софтины фиксит у себя апстрим. С хорошей вероятностью > патч, который фиксит проблему, подойдет к той версии пакета, которая в > stable или в oldstable. Но может быть и так, что: > 1) Патч не подходит (не накладывается) С чего бы это? > 2) Софтина давно не поддерживается разработчикам Выкинуть и собрать свежую, поддерживаемую. > Что тогда? > > А вот возьмем другой CVE-2015-8668 на libtiff5 - во, тут думать надо, > > апстрим не разродился патчем - поэтому и починим как разродиться. > И если не разродится, то так и забьют? ) Таки да. Багов вида "не работает" в трекере - вагон, и на большенство - забито с прибором.
Re: ifupdown / systemd
On 13/01/16 07:14, Victor Wagner wrote: > Самому openvpn глубоко пофиг, как называется то, что указали в опции > --config. Что указали, то и читает. Конечно. > Назвать его .conf - дебиановское решение. Нет. openvpn-2.3.10 % grep conf contrib/multilevel-init.patch # Start every .conf in $work and run .sh if exists - for c in `/bin/ls *.conf */*.conf 2>/dev/null`; do + for c in `find * -name "*.conf" 2>/dev/null`; do bn=${c%%.conf} openvpn-2.3.10 % cat sample/Makefile.am ... client.ovpn: sample-config-files/client.conf -rm -f client.ovpn cp "$(srcdir)/sample-config-files/client.conf" client.ovpn ... -- sergio