Re: Как узнать какой пакет предоставляет сервис DBus
23.03.2023, Victor Wagner написал(а): > По идее freedesktop.org и создавалась для того, чтобы обеспечить общие > для всех стандарты и интероперабельность между различными DE. Но эта > миссия была успешно провалена. В otpclient она была провалена дважды, судя по issue на github. В первый раз - при привязке к гному. Во второй раз - когда в гноме выкинули соответствующий вызов dbus. Судя по https://github.com/paolostivanin/OTPClient/issues/185, где выпилили скриншоты вообще - будет что-то cross-DE, но когда - непонятно. На мой взгляд, у дебиановского пакета баг - gnome-shell/gnome-screenshot в Recommends отсутствуют. Было бы понятно сразу. -- Stanislav
Re: Как узнать какой пакет предоставляет сервис DBus
В Thu, 23 Mar 2023 23:40:35 +0700 Max Nikulin пишет: > On 23/03/2023 13:46, Victor Wagner wrote: > > > > Вот есть приложение, которое умеет извлекать полезную информацию из > > QR-кода. У него есть функция "take screenshot" поскольку QR-код, из > > которого надо извлекать информацию, часто бывает в окошке браузера > > на том же экране, что и приложение. (речь про otpclient) > > Речь ведь про https://github.com/paolostivanin/OTPClient ? Я мельком Речь конечно же про https://packages.debian.org/bullseye/otpclient но да, апстрим у него именно там. > > Не уверен, что gnome.Shell будет предоставлять кто-нибудь, кроме > gnome shell. Ну почему бы и нет? Желание использовать отдельные утилиты из Gnome не используя всего gnome есть у многих. > Интересно, вот такое только для песочниц или остальные > программы тоже могут пользоваться? > > busctl --user introspect org.freedesktop.portal.Desktop > /org/freedesktop/portal/desktop org.freedesktop.portal.Screenshot Пользоваться могут, но видимо не xотят > Наткнулся на детектив про Gimp. Если видит KDE, то отказывается > захватывать экран при выключенном compositing: > https://bugzilla.opensuse.org/show_bug.cgi?id=1100765#c15 > Сложилось ощущение, что приходится перебирать интерфейсы, которые > могут предоставлять разные DE, а универсального решения нет. По идее freedesktop.org и создавалась для того, чтобы обеспечить общие для всех стандарты и интероперабельность между различными DE. Но эта миссия была успешно провалена. -- Victor Wagner
Re: Как узнать какой пакет предоставляет сервис DBus
On 23/03/2023 13:46, Victor Wagner wrote: Вот есть приложение, которое умеет извлекать полезную информацию из QR-кода. У него есть функция "take screenshot" поскольку QR-код, из которого надо извлекать информацию, часто бывает в окошке браузера на том же экране, что и приложение. (речь про otpclient) Речь ведь про https://github.com/paolostivanin/OTPClient ? Я мельком глянул в код, заметил там clipboard, а вот screenshot на глаза не попался. Хотя именно для OTP я предпочел бы перетащить картинку мимо буфера обмена. The name org.gnome.Shell.Screenshot was not provided by any service file. ... Задача - найти наиболее подходящее приложение которое бы предоставило этот сервис, dbus и позволило функции заработать. Как я понимаю, на то и DBus чтобы были альтернативные варианты. Не уверен, что gnome.Shell будет предоставлять кто-нибудь, кроме gnome shell. Интересно, вот такое только для песочниц или остальные программы тоже могут пользоваться? busctl --user introspect org.freedesktop.portal.Desktop /org/freedesktop/portal/desktop org.freedesktop.portal.Screenshot Наткнулся на детектив про Gimp. Если видит KDE, то отказывается захватывать экран при выключенном compositing: https://bugzilla.opensuse.org/show_bug.cgi?id=1100765#c15 Сложилось ощущение, что приходится перебирать интерфейсы, которые могут предоставлять разные DE, а универсального решения нет. Вопрос в том, можно ли с помощью базы apt, debtags и тому подобных средств узнать, какие у нас в дистрибутиве есть пакеты, которые предоставляют определенный сервис DBus? Скорее https://codesearch.debian.net/search?q=org.gnome.Shell.Screenshot но обнадеживающего ответа не заметно.
Re: Нужен прокси, но хитрый
On Thu, Mar 23, 2023 at 06:15:12PM +0300, Andrey Jr. Melnikov wrote: > > Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге > > критериям. В эти критерии могут входить параметры соединения, выбираемые > > на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного > > исходящего от сквида src_ip сделать пул адресов -- задача на дом. > И почему на том-же nginx это будет сделать проще и гибчче - тоже на дом, как > бонусная. Nginx это реверсный прокси, он не умеет CONNECT, который товарищу очень хочется, да ещё со своими кастомными хедерами. Хотя исходная постановка задачи допускает разные толкования и предположения, что там хочется... -- Eugene Berdnikov
Re: Нужен прокси, но хитрый
Eugene Berdnikov wrote: > On Thu, Mar 23, 2023 at 04:20:16PM +0400, Maksim Dmitrichenko wrote: > >чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov <[1]b...@protva.ru>: > > Ну, это всё незамысловато строгается через squid+iproute+iptables... > > Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз. > > > >Таким образом нельзя программно-протокольным образом выбрать группу > >адресов, через которую отправится предстоящее соединение. Если я > > правильно > >понял предлагаемую схему. > Что значит "программно-протокольным образом"? Явно ему хочется посмотреть во внутрь протокола. > Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге > критериям. В эти критерии могут входить параметры соединения, выбираемые > на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного > исходящего от сквида src_ip сделать пул адресов -- задача на дом. И почему на том-же nginx это будет сделать проще и гибчче - тоже на дом, как бонусная.
Re: Нужен прокси, но хитрый
On Thu, Mar 23, 2023 at 04:20:16PM +0400, Maksim Dmitrichenko wrote: >чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov <[1]b...@protva.ru>: > Ну, это всё незамысловато строгается через squid+iproute+iptables... > Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз. > >Таким образом нельзя программно-протокольным образом выбрать группу >адресов, через которую отправится предстоящее соединение. Если я правильно >понял предлагаемую схему. Что значит "программно-протокольным образом"? Сквид умеет задавать src_ip исходящих соединений, по заданным в конфиге критериям. В эти критерии могут входить параметры соединения, выбираемые на стороне клиента, конкретно dst_ip и dst_port. Как вместо одного исходящего от сквида src_ip сделать пул адресов -- задача на дом. -- Eugene Berdnikov
Re: Нужен прокси, но хитрый
Maksim Dmitrichenko wrote: > [-- text/plain, encoding base64, charset: UTF-8, 75 lines --] > чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov : > > On Thu, Mar 23, 2023 at 01:26:04PM +0400, Maksim Dmitrichenko wrote: > > >Хочется поиметь такой HTTP Proxy сервер, который: > > >а) будет балансировать соединения из внутренней сети в Интернет по > > >определенному набору внешних айпишников (к каждому из которых на хосте > > >прокси имеется, например, VPN-соединение, то есть айпишники не на > > >интерфейсах хоста, где запущен прокси, а до них ещё один хоп). > > >б) умеет группировать айпишники по группам (с помощью конфигурации), а > > >клиент имеет возможность выбрать группу (например в заголовке к методу > > >CONNECT). > > > > Ну, это всё незамысловато строгается через squid+iproute+iptables... > > Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз. > Таким образом нельзя программно-протокольным образом выбрать группу > адресов, через которую отправится предстоящее соединение. Если я правильно > понял предлагаемую схему. Можно. Если ты конечно по пакету с tcp syn сможешь угадать, в что-же там унутре такое и куда его деть. [...] > Нормальное поведение любой REST-овой APIшки возвращать 429, если превышен, > например, RPS к её вызовам. Вам что-то буйные мерещатся в каждом абзаце. А чем этот твой REST crap отличается от Васи с IE6.0 ? Тем, что Вася на стуле и один - а твое намазано по кластеру под докером/киберентсом/чётамсейчасмодно?
Re: Нужен прокси, но хитрый
чт, 23 мар. 2023 г. в 14:01, Eugene Berdnikov : > On Thu, Mar 23, 2023 at 01:26:04PM +0400, Maksim Dmitrichenko wrote: > >Хочется поиметь такой HTTP Proxy сервер, который: > >а) будет балансировать соединения из внутренней сети в Интернет по > >определенному набору внешних айпишников (к каждому из которых на хосте > >прокси имеется, например, VPN-соединение, то есть айпишники не на > >интерфейсах хоста, где запущен прокси, а до них ещё один хоп). > >б) умеет группировать айпишники по группам (с помощью конфигурации), а > >клиент имеет возможность выбрать группу (например в заголовке к методу > >CONNECT). > > Ну, это всё незамысловато строгается через squid+iproute+iptables... > Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз. > Таким образом нельзя программно-протокольным образом выбрать группу адресов, через которую отправится предстоящее соединение. Если я правильно понял предлагаемую схему. > Вот только установка своих заголовков может быть лишь в палате для буйных, > где каждый себе своего клиента строчит и свои заголовки в запрос вставить > может. А простые юзеры могут лишь в настройках браузера порт или ip-адрес > прокси выбрать (по порту и ip сквид разрулить трафик может). > Причем здесь браузер и простые юзеры? Что вообще за чушь вы тут понаписали, буйный вы наш? Есть, например, такие инструменты как haproxy, и они, понятное дело, нужны совсем не для того, чтобы некий Уасилий через него в своём Internet Explorer'е сайтики открывал. > >в) умеет гарантировать, что для отдельного взятого клиента очередной > >CONNECT поедет через такой айпи, через который данный клиент ещё не > >законнекчен или выдаст ошибку (типа 429). Идентификацию клиента можно > >делать авторизацией или каким-то уникальным значением, которое > передается, > >например, опять же в одном из заголовков к методу CONNECT. > > Боюсь, для столь удивительной задачи ничего готового не найти. > Тем более что статус 4xx по превышению числа коннекций это точно не для > людей, даже из палаты для буйных. :) > Нормальное поведение любой REST-овой APIшки возвращать 429, если превышен, например, RPS к её вызовам. Вам что-то буйные мерещатся в каждом абзаце. И задача, в общем-то, вполне прозаическая для тех, кому приходится работать со сторонними REST API, которые режут RPS по IP. То, что вам в жизни не приходилось этого делать, не делает задачу удивительной ни на йоту. -- With best regards Maksim Dmitrichenko
Re: Нужен прокси, но хитрый
On Thu, Mar 23, 2023 at 01:26:04PM +0400, Maksim Dmitrichenko wrote: >Хочется поиметь такой HTTP Proxy сервер, который: >а) будет балансировать соединения из внутренней сети в Интернет по >определенному набору внешних айпишников (к каждому из которых на хосте >прокси имеется, например, VPN-соединение, то есть айпишники не на >интерфейсах хоста, где запущен прокси, а до них ещё один хоп). >б) умеет группировать айпишники по группам (с помощью конфигурации), а >клиент имеет возможность выбрать группу (например в заголовке к методу >CONNECT). Ну, это всё незамысловато строгается через squid+iproute+iptables... Даёте группе свой выходной src_ip, и через ip rule его на нужный шлюз. Вот только установка своих заголовков может быть лишь в палате для буйных, где каждый себе своего клиента строчит и свои заголовки в запрос вставить может. А простые юзеры могут лишь в настройках браузера порт или ip-адрес прокси выбрать (по порту и ip сквид разрулить трафик может). >в) умеет гарантировать, что для отдельного взятого клиента очередной >CONNECT поедет через такой айпи, через который данный клиент ещё не >законнекчен или выдаст ошибку (типа 429). Идентификацию клиента можно >делать авторизацией или каким-то уникальным значением, которое передается, >например, опять же в одном из заголовков к методу CONNECT. Боюсь, для столь удивительной задачи ничего готового не найти. Тем более что статус 4xx по превышению числа коннекций это точно не для людей, даже из палаты для буйных. :) -- Eugene Berdnikov
Нужен прокси, но хитрый
Всем привет! Ищу решение следующей задачи и не нахожу готового велосипеда. Может кто подскажет? Хочется поиметь такой HTTP Proxy сервер, который: а) будет балансировать соединения из внутренней сети в Интернет по определенному набору внешних айпишников (к каждому из которых на хосте прокси имеется, например, VPN-соединение, то есть айпишники не на интерфейсах хоста, где запущен прокси, а до них ещё один хоп). б) умеет группировать айпишники по группам (с помощью конфигурации), а клиент имеет возможность выбрать группу (например в заголовке к методу CONNECT). в) умеет гарантировать, что для отдельного взятого клиента очередной CONNECT поедет через такой айпи, через который данный клиент ещё не законнекчен или выдаст ошибку (типа 429). Идентификацию клиента можно делать авторизацией или каким-то уникальным значением, которое передается, например, опять же в одном из заголовков к методу CONNECT. Знает ли кто-нибудь что-нибудь подобное? -- With best regards Maksim Dmitrichenko
Re: Как узнать какой пакет предоставляет сервис DBus
В Thu, 23 Mar 2023 10:55:22 +0300 Иван Лох пишет: > On Thu, Mar 23, 2023 at 09:46:42AM +0300, Victor Wagner wrote: > > > > Вопрос в том, можно ли с помощью базы apt, debtags и тому подобных > > средств узнать, какие у нас в дистрибутиве есть пакеты, которые > > предоставляют определенный сервис DBus? > > apt-file search org.gnome.Shell.Screenshot > gnome-shell-common: > /usr/share/dbus-1/interfaces/org.gnome.Shell.Screenshot.xml > Это как видим не то. Это описание этого интерфейса DBus, а не его реализация. -- Victor Wagner
Re: Как узнать какой пакет предоставляет сервис DBus
On Thu, Mar 23, 2023 at 09:46:42AM +0300, Victor Wagner wrote: > > Вопрос в том, можно ли с помощью базы apt, debtags и тому подобных > средств узнать, какие у нас в дистрибутиве есть пакеты, которые > предоставляют определенный сервис DBus? apt-file search org.gnome.Shell.Screenshot gnome-shell-common: /usr/share/dbus-1/interfaces/org.gnome.Shell.Screenshot.xml -- И.Л.
