Re: Выполнение привелигированых команд пользователем.

[Коротаев Руслан]

В сообщении от [Вс 2015-11-22 01:53 +0200]
Oleksandr Gavenko  пишет:

> Для меня привычные команды:
> 
>   $ sudo halt
>   $ sudo pm-suspend
> 
> Они требуют прав root. Но пользователь декстопа должен иметь право выполнять
> эти операции!
> 
> Как это сделано в популярных DE? В ~/.fvwm/config для себя я пропишу с sudo,
> но выглядит как то некошерно...

Для управления питанием от имени непривилегированного пользователя
необходим polkit (установите пакет policykit-1). Если вы находитесь в
локальной пользовательской сессии systemd-logind, и нет других активных
сессий, приведенные ниже команды сработают и без привилегий
суперпользователя. В противном случае (например, вследствие того, что
другой пользователь вошел в систему в tty), systemd автоматически
запросит у вас пароль суперпользователя [1].

Завершить работу и перезагрузить систему:
$ systemctl reboot

Завершить работу и выключить компьютер (с отключением питания):
$ systemctl poweroff

Перевести систему в ждущий режим:
$ systemctl suspend

Перевести систему в спящий режим:
$ systemctl hibernate

Перевести систему в режим гибридного сна (или suspend-to-both):
$ systemctl hybrid-sleep

[1]: https://wiki.archlinux.org/index.php/Systemd_(Русский)

-- 
Коротаев Руслан
http://blog.kr.pp.ru/

Re: Выполнение привелигированых команд пользователем.

[Oleksandr Gavenko]

On 2015-11-22, Жанибек Нагашыбай wrote:

> Можно в sudoers указать, что данные команды можно выполнять без ввода
> пароля.

Как разработчику мне удобней с:

  $ cat /etc/sudoers.d/user
  user  ALL=(ALL) NOPASSWD: ALL

Для настройки прав для рядового десктопного пользователя зависимоть от sudo
какая то странная.

Пользователь клацнет элемент меню для выключения компьютера. Интересно как это
организовано что бы повторить поведение в настройках FVWM.

-- 
Best regards!

Re: systemd

[Dmitry E. Oboukhov]

On 02:53 Sun 22 Nov , Oleksandr Gavenko wrote:
> On 2015-11-12, Dmitry E. Oboukhov wrote:

>> правда тут полезли неофиты из гугла и прочих копрораций и начали
>> внедрять бинарные расширения к HTTP. увы и ах - тоже дурная тенденция.

> В HTTP 2 бинарность удобна разработчикам протокола.

дык они - дебилы, поэтому она им и "удобна"

> В одном соединении можно проталкивать множество ресурсов одновременно.

> Из https://tools.ietf.org/html/rfc7540:

для того чтобы отправлять данные пакетами от разных stream не нужно
было вводить бинарность.
можно было оформить каждый пакет по rfc822 с индивидуальным тегом,
хранящим ID.
это дало бы помимо человекочитаемости еще и возможность расширения на
уровне заголовков.

> +---+
> | Length (24)   |
> +---+---+---+
> |   Type (8)|   Flags (8)   |
> +-+-+---+---+
> |R| Stream Identifier (31)  |
> +=+=+
> |   Frame Payload (0...)  ...
> +---+

> Вроде в рамках одного Stream Identifier данные еще дробяться.

> Представте мешанину, когда отдается много кусочков вразброс.

и если эти кусочки были бы текстовыми, то в этой мешанине можно было
бы разбираться

> Поток не человеко-читабельный, потому данные упаковали, как было удобно.

Поток не человеко-читабельный, потому ЧТО данные упаковали, как было
удобно.

fixed
-- 

. ''`.   Dmitry E. Oboukhov
: :’  :   email: un...@debian.org jabber://un...@uvw.ru
`. `~’  GPGKey: 1024D / F8E26537 2006-11-21
  `- 1B23 D4F8 8EC0 D902 0555  E438 AB8C 00CF F8E2 6537


signature.asc
Description: Digital signature

Re: systemd

[Oleksandr Gavenko]

On 2015-11-13, Victor Wagner wrote:

> On Fri, 13 Nov 2015 15:43:36 +0300
> Max Dmitrichenko  wrote:
>
>> типу 10.0.0.0/8 в пространстве IPv4. Однако, к сожалению, не смотря на
>> то, что на дворе 21-й век, не все изобретатели протоколов на это идут.
>> Взять хотя бы тот же закиданный каками USB за то, что они не дали ID
>> для DIY-девайсов.
>> 
>
> Так они специально на это идут. Основная болезнь XXI века заключается в
> том, что кто угодно - изобретатели протоколов, вендоры железок, авторы
> программ, не хотят отдавать контроль за своим детищем пользователю.
>

Одноразовая расценка за VID для USB порядка 1000$, но даже там предприняли
шаги для предотвращение сквотинга пространства, за 65 млн можно выкупить все
пространство.

UUID и вообще любая последовательность случайных байтов длиннее 16 штук решает
проблему централизованой регистрации меток/имен.

Но какой же комитет откажется от продажи идентификаторов? ))

-- 
Best regards!

Re: systemd

[Oleksandr Gavenko]

On 2015-11-14, Egorov N.V. wrote:

> Сейчас практически невозможен форк firefox, не говоря уже о форке
> systemd. Первый невозможен из-за размеров проекта и внутренней кухни,
> второй - по причине бесконечного изменения внешнего API. Но это лшь
> проявления одного и того-же явления - никто не хотел чтобы этот код
> модифицировали другие люди. 

Firefox построен на Mozilla Platform. Платформа предоставляет довольно
стабильный хотя и совершенствуещийся API.

Вот если они выкинут XUL и JavaScript - тогда можно говорить что Mozilla
закрывает повторное использование для сторонних.

Со временем бурная деятельность WhatWG/W3 утихнет, родится ECMAScript 7.
Реализации браузеров замрут как TeX на версии 3.1415, будут обьявлены
эталонными реализациями.

Если форкать Firefox сейчас - не хватит сил следовать WhatWG/W3.

-- 
Best regards!

Re: systemd

[Oleksandr Gavenko]

On 2015-11-16, Max Dmitrichenko wrote:

> Ничто и никто не мешает китайцам (да и не только им) уже сейчас взять
> просто какой-нить не используемый VendorID и начать фигачить под него
> девайсы и драйвера (при необходимости). Однако этого не происходит. Из
> чего следует, что ваши предположения о подобной угрозе сильно
> преувеличины.

Есть случаи, когда китайские VID/PID конфликтуют с именитыми вендорами.
Разнородные устройства (принтер и клавиатура) имели одинаковые VID/PID.

Китайцы делают функциональные клоны микросхем и вставляют оригинальные
VID/PID, так что оригинальный проприетанрый софт работает с устройствами, не
различая их.

Некоторые вендоры пытаются обнаружить клоны. Некоторые проприетарные JTAG
программы наказывают клон в виде сброса VID/PID в :.

Мне кажется что VID/PID не играет роли для классовых устройств, по крайней
мере в Linux.

-- 
Best regards!

Re: systemd

[Oleksandr Gavenko]

On 2015-11-22, Dmitry E. Oboukhov wrote:

>> Представте мешанину, когда отдается много кусочков вразброс.
>
> и если эти кусочки были бы текстовыми, то в этой мешанине можно было
> бы разбираться

Не нужно там разбираться.

Вот в бесплатной книжке http://http2-explained.haxx.se/ написано:

  Internally, curl will convert incoming http2 headers to HTTP 1.x style headers
  and provide them to the user, so that they will appear very similar to
  existing HTTP. This allows for an easier transition for whatever is using curl
  and HTTP today. Similarly curl will convert outgoing headers in the same
  style. Give them to curl in HTTP 1.x style and it will convert them on the fly
  when talking to http2 servers. This also allows users to not have to bother or
  care very much with which particular HTTP version that is actually used on the
  wire.

Аналогично с инструментами разработчика в браузерах.

nc и telnet уже не прокатят, в книжке подталкивают что SSL/TLS трафик тоже с
telnet не рассмотришь.

В общем отлавливать ошибки кодирования протокольного уровня обычным сметрным
не придется, а для прикладного уровня инструменты **уже работают**, при чем
я как ранее использовал "curl -v" или Firefox Web Developer так и сейчас
продолжаю ими пользоваться.

В книжке только несколько **конкретных** примеров, когда HTTP/2 дает
преимущество:

 * 1 TCP соединение, вместо нескольких. Избегаем задержет на TCP рукопожатие,
   не знаю, может есть также плюс и для SSL/TLS. Итого страничики через
   мобильное GPRS будут заметно быстрее открываться.

 * Облегчится структура сборки проектов - нет необходимости в спрайтинге (кучу
   картинок слепить в 1 большую), инлайнинге (CSS в HTML), шардинге (HTTP/1
   рекомендует максимум 2 конекта к одному хосту, потому разносили на кучу
   разрозненых).

Остальное я не понимаю и в самой книжке написано что нифига не ясно как будут
пользоваться HTTP/2, все ждут револющионных применений, которые изменят мир.
Пока их нет.


-- 
Best regards!

Re: Как работает локальный DNS кеш?

[Oleksandr Gavenko]

On 2015-11-22, Oleksandr Gavenko wrote:

> Как менеджеры сетевых подключений (connman, wicd, NetworkManager) знают о том
> что нужно передать информацию от DHCP к DNS-кешу? На каждый нужно изучать
> документацию?
>
> Или например не трогать /etc/resolve.conf?
>
> И нужен ли мне локальный DNS кеш?

Пока не знаю ответы, но есть пакет resolvconf, который дружит с многими
другисми пакетами Debian, из resolvconf-1.78/README:

  Resolvconf works with most interface configurers in Debian ('(*)' below
  meaning "with some manual configuration"): 

 isc-dhcp-client, dhcpcd, pump, udhcpc
 ppp
 ifupdown
 network-manager

  DNS caches:

 bind9(*), djbdns dnscache, dnsmasq, nscd, pdnsd

  DNS recursing nameservers:

 bind9(*), pdns-recursor(*), unbound

  and with any program that uses a DNS client library that consults
  /etc/resolv.conf to obtain its list of nameservers:

 the GNU C Library resolver library
 adns
 the djbdns resolver library
 FireDNS

В пакете openresolv поменьше документации.

-- 
Best regards!

Re: Как работает локальный DNS кеш?

[Artem Chuprina]

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Sun, 22 Nov 2015 
19:06:38 +0200:

 >> Как менеджеры сетевых подключений (connman, wicd, NetworkManager) знают о 
 >> том
 >> что нужно передать информацию от DHCP к DNS-кешу? На каждый нужно изучать
 >> документацию?
 >>
 >> Или например не трогать /etc/resolve.conf?
 >>
 >> И нужен ли мне локальный DNS кеш?

 OG> Пока не знаю ответы, но есть пакет resolvconf, который дружит с многими
 OG> другисми пакетами Debian, из resolvconf-1.78/README:

resolvconf у меня живет весьма неплохо, но я не пользуюсь connman/nm.
Пользуюсь wicd, и про него знаю, что он сам эту информацию не трогает,
ею занимается dhclient (или кто там у тебя работает с DHCP) в связке с
resolvconf.

И кэшем работает dnsmasq.  На домашнем сервере - bind9, и ему приходится
вручную добавлять скрипт, звездочка в документации неспроста.  А с
dnsmasq работает из коробки.

 OG>   Resolvconf works with most interface configurers in Debian ('(*)' below
 OG>   meaning "with some manual configuration"): 

 OG>  isc-dhcp-client, dhcpcd, pump, udhcpc
 OG>  ppp
 OG>  ifupdown
 OG>  network-manager

 OG>   DNS caches:

 OG>  bind9(*), djbdns dnscache, dnsmasq, nscd, pdnsd

 OG>   DNS recursing nameservers:

 OG>  bind9(*), pdns-recursor(*), unbound

 OG>   and with any program that uses a DNS client library that consults
 OG>   /etc/resolv.conf to obtain its list of nameservers:

 OG>  the GNU C Library resolver library
 OG>  adns
 OG>  the djbdns resolver library
 OG>  FireDNS

 OG> В пакете openresolv поменьше документации.

 OG> -- 
 OG> Best regards!

Как работает локальный DNS кеш?

[Oleksandr Gavenko]

Настраивал поддомены у регистратора и сайты на веб-сервере и попался на том
что ни в какую страница не подгружается.

По умолчанию Debian никаких DNS кешей не устанавливает.

Т.е. либо приложение самостоятельно кеширует запросы к DNS либо каждый раз
опрашивает.

По:

  $ cat /etc/resolv.conf
  # Generated by Connection Manager
  nameserver 127.0.0.1
  nameserver ::1

понял что виновен connman. Поделие какое то недопиленое. Опции сбросить DNS
кеш в connmanctl нету. Есть опция:

  $ cat /etc/default/connman
  DAEMON_OPTS='--nodnsproxy'

выключить локальный кеш.

Я отправил баг в Debian BTS, на официальном BTS проекта недоступна
регистрация, в офиц. IRC молчат...

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805797

В cлучае connman мне ясно что аналог вызова:

  $ dhclient wlan0

делает connman и от туда получает адреса DNS серверов, стартуя локальный на
localhost:53

Есть разные DNS-кеши, например я нашел nscd, dnsmasq, named/bind.

Как менеджеры сетевых подключений (connman, wicd, NetworkManager) знают о том
что нужно передать информацию от DHCP к DNS-кешу? На каждый нужно изучать
документацию?

Или например не трогать /etc/resolve.conf?

И нужен ли мне локальный DNS кеш?

-- 
Best regards!

Re: systemd

[Artem Chuprina]

Oleksandr Gavenko -> debian-russian@lists.debian.org  @ Sun, 22 Nov 2015 
13:44:53 +0200:

 >>> Представте мешанину, когда отдается много кусочков вразброс.
 >>
 >> и если эти кусочки были бы текстовыми, то в этой мешанине можно было
 >> бы разбираться

 OG> Не нужно там разбираться.

 OG> Вот в бесплатной книжке http://http2-explained.haxx.se/ написано:

 OG>   Internally, curl will convert incoming http2 headers to HTTP 1.x style 
headers
 OG>   and provide them to the user, so that they will appear very similar to
 OG>   existing HTTP. This allows for an easier transition for whatever is 
using curl
 OG>   and HTTP today. Similarly curl will convert outgoing headers in the same
 OG>   style. Give them to curl in HTTP 1.x style and it will convert them on 
the fly
 OG>   when talking to http2 servers. This also allows users to not have to 
bother or
 OG>   care very much with which particular HTTP version that is actually used 
on the
 OG>   wire.

 OG> Аналогично с инструментами разработчика в браузерах.

 OG> nc и telnet уже не прокатят, в книжке подталкивают что SSL/TLS трафик тоже 
с
 OG> telnet не рассмотришь.

Это вранье.  Остальное, вероятно, тоже.

 OG> В общем отлавливать ошибки кодирования протокольного уровня обычным 
сметрным
 OG> не придется, а для прикладного уровня инструменты **уже работают**, при чем
 OG> я как ранее использовал "curl -v" или Firefox Web Developer так и сейчас
 OG> продолжаю ими пользоваться.

 OG> В книжке только несколько **конкретных** примеров, когда HTTP/2 дает
 OG> преимущество:

 OG>  * 1 TCP соединение, вместо нескольких. Избегаем задержет на TCP 
рукопожатие,
 OG>не знаю, может есть также плюс и для SSL/TLS. Итого страничики через
 OG>мобильное GPRS будут заметно быстрее открываться.

По сравнению с чем он дает преимущество?  С HTTP/1.1, в котором это
ввели, и который все давно уже умеют?

 OG>  * Облегчится структура сборки проектов - нет необходимости в спрайтинге 
(кучу
 OG>картинок слепить в 1 большую), инлайнинге (CSS в HTML), шардинге (HTTP/1
 OG>рекомендует максимум 2 конекта к одному хосту, потому разносили на кучу
 OG>разрозненых).

 OG> Остальное я не понимаю и в самой книжке написано что нифига не ясно как 
будут
 OG> пользоваться HTTP/2, все ждут револющионных применений, которые изменят 
мир.
 OG> Пока их нет.

Во-во...