уважаемые, подскажите пожалуйста. бьюсь уже наверное часа два с плагином для дженкинса (github pull request builder). не воспринимает мои креденшелы и хоть ты тресни

Security mode какой стоит ? known_hosts ?

из консоли сервера su - jenkins; ssh user@host

сек

прими хост и выйди из сессии

после этого полетит

не-не

я могу подключиться

и по ссш, и через курл с логином и паролем

уважаемые, подскажите пожалуйста. бьюсь уже наверное часа два с плагином для дженкинса (github pull request builder). не воспринимает мои креденшелы и хоть ты тресни

А логи чего пишут?

а вот через сраный плагин - не хочет

не смарел, кстати

ща

я могу подключиться

с какой машины ? с jenkins ? под user = jenkins ?

с дженкинс машинки, под юзером дженкинс, с моим ключом, который я добавил на гитхабе и закинул его в .ssh

это с токеном. с логином и пассом - такая же байда

в логах ничо

Версии плагинов последние?

угу

и 2.95 женькинс

Добрый день! Как в Traefik выставить Strict-Transport-Security?

это с токеном. с логином и пассом - такая же байда

это похоже на проблему credentials plugin

недавно видел как он вместо кредов экспортирует entry id

хэм, ща посмотрю

кто-то сталкивался что gitlab не коннектится по ssh по ключу как клиент? с хоста с этим же ключом без проблем

госпади

реально

недавно видел как он вместо кредов экспортирует entry id

Брат, спасибо!

я не подумал даже, что дело может быть в этом

просто обновил плагин и все

просто обновил плагин и все

Ты же сказал последние стоят =)

Ты же сказал последние стоят =)

не все, как оказалось)

я искаробки ставил

Ну пипец =))

думал, что все)))))))))

та уже сам себя выговорил за это)

3 часа в трубу)))

Опубликован метод скрытия частей кода при выводе изменений при помощи команды "git diff", которая часто используется для изучения присылаемых патчей. Добавив в код escape-последовательность "[8m" атакующий может сделать невидимой часть при выводе на экран с использованием терминала, поддерживающего команды VT100. via OpenNews.opennet.ru: Общая лента новостей http://ift.tt/2BCt5fM

збс

А кто-нибудь настраивал IKEv2?

А кто-нибудь настраивал IKEv2?

куда?

Не знаю) мне нужен впн на айось

Короче, стороннее приложение (бинарь) использует nginx как компонент - менеджит его конфиги и делает релоад когда нужно. Где-то в коде этого приложения есть косячок, когда прилетает куча релоадов сразу. Nginx при этом плодит процессы (worker process is shutting down) и забивает память тачилы напрочь

worker_shutdown_timeout или как его там. выстави в 10 секунд, и оно принудительно прибьёт остатки

Salavat, ну и в чём проблема? strongswan какой-нить

Ох ты, вроде неплохо http://zakupki.gov.ru/epz/contract/contractCard/common-info.html?reestrNumber=1771014610217000391

ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ на выполнение услуг (работ) по обеспечению информационной безопасности органов прокуратуры Российской Федерации, а также по обеспечению этих органов информационно-телекоммуникационной инфраструктурой

налетай )

Salavat, ну и в чём проблема? strongswan какой-нить

О. Буду читать. Спасибо

Не знаю) мне нужен впн на айось

Сервер или клиент?

@aftertime ящитаю ссылка выше достойна блога )

Схоронил

Сервер или клиент?

Сервер

то чуство, когда чем больше разбираешься тем больше непонятно ?

Начни с малого - загони своих двух программистов в гит. Этот произойдёт не мгновенно. Пока будут вникать и привыкать - ты определишься с потребностями и выберешь продукт для построения CI. Гитовый репозиторий потом перенесешь при необходимости на другой сервер, это несложно.

worker_shutdown_timeout или как его там. выстави в 10 секунд, и оно принудительно прибьёт остатки

Если бы так просто все было, нельзя терять запросы клиентские

@SalemGolem > Если бы так просто все было, нельзя терять запросы клиентские а команда релоада nginx-а жестко забита в апликуху, или ее можно самому указать?

это бинарь, я не могу его пропатчить

там по сути можно указать, какой скрипт для релоада дергать, но вопрос в этом и состоит, как в этом кастомном скрипте определить воркеры, которые находятся в состоянии shutdown, без грепанья вывода ps,pgrep

в общем, вижу два варианта: 1. фронтом поставить другой nginx как reverse-proxy и никогда его не пинать. в таком случае бэковый nginx можно хоть каждые 5 секунд убивать. для клиента это будет выглядеть как простые задержки 2. вместо передергивания nginx-а приложением, можно дергать скрипт вроде #!/bin/sh flock -n /run/reload_nginx -c 'sleep 15 ; service nginx reload' || :

@SalemGolem ^^^^^^^^^^^^^^^^^^^^^

1. nope, менеджить 2 джикса ну его в жопу 2. примерно так и сделал, но немного хитрее, мой скрипт "копит" релоды от аппликухи, потом релоадит джиксу по настоящему, опираясь на существование воркеров в статусе shutdown

но вот скрипт работает через pgrep

ERROR: S client not available

я хочу от этого избавиться

покопал искходники - кроме как комманд лайн title у этого процесса нифига не меняется %(

я тоже подумал, что первый вариант покажется вариантом для "особых ценитеелей"

а чем второй не устраивает? с первого дергания скрипта ждется какое-то время (flock наше фсиооо) и после этого дергается скрипт. все кто за это время прилетают - идут лесом

если не хочется жетско время задавать - заюзай pstree и жди смерти всех потомков главного процесса

@SalemGolem ^^^^^^^^^^^^^^^

15 секунд может не хватить, иногда бывают реквесты по 60 сек (долгий бекенд от сторонних людей)

тогда или времени побольше, или man pstree и хитрый скрипт (я, как ленивый человек, советую sleep подлиннее, но сам бы писал с применением pstree)

@SalemGolem как-то так попробуй пиды получать: PIDS=$(pstree -p $(cat /run/nging.pid) | sed -nre 's/^.+\(([0-9]+)\)$/\1/p') ...

кстати, можно вообще так сделать: mkdir /sys/fs/cgroup/reload_nginx PIDS=.... echo "${PIDS}" > /sys/fs/cgroup/reload_nginx/tasks echo "/some/script" > /sys/fs/cgroup/reload_nginx/release_agent и уже /some/script-ом выполняешь действия, которые запланировал на окончание перегрузки nginx-а только не забудь так же этот каталог удалить

@SalemGolem ^^^^^^^^^^^^^^^

<s>погугли про cgroup release_agent или подсмотри оное в systemd или OpenRC</s> почитай документацию к ядру, там все доступно

ты выцепляешь пиды всех процессов

а нужно только те, которые в shutdown state

короче всю задачу можно свести к тому, что надо найти разницу между обычным воркером и воркером в shutdown state не опираясь на command line процесса

https://github.com/nginx/nginx/blob/afad21917584e9b452ba33ce3485edde5615b859/src/os/unix/ngx_process_cycle.c#L761 вот по сути этот кусок

лезбиан ?

http://forum.ixbt.com/topic.cgi?id=15:24706 Был такой дистр, но помер давно, как я понимаю.

@SalemGolem так релоад дергаешь ПОСЛЕ того, как собрал ПИД-ы соответсвенно, после релоада все потомки (воркеры) должны пасть смертью храбрых и когда это случится, можно заходить на новую итерацию

здравствуйте приехали, мастер процесс не будет ждать пока убьются все воркеры, он их рестартит не дожидаясь падения ВСЕХ старых воркеров

ладно, спасибо, помудрю еще что-нибудь

А кто-нибудь настраивал IKEv2?

Кто-нибудь да настраивал. Но твой истинный вопрос ведь не в этом, не так ли?

@SalemGolem так вам кататься или ша ^U возможно, я чего-то непонял из задачи что требуется? пока воркеры предыдущей итерации не ушли, второй подряд reload дергать нельзя. так? в таком случае имеем следующую картину 1. до reload-а пиды: pidM0 (pidW0_1, pidW0_2 ... pidW0_n) 2. релоадим 3. имеем pidM0 (pidW1_1, pidW0_2 ... pidW1_n) т.е. воркер 2 с устаревшим конфигом еще работает ждем когда он (и все его "поколения") последует примеру ЕБН-а (устанет и уйдет) 4. когда все старые ушли, и есть только новые воркеры, если надо, снова nginx-у говорим перечитать конфиг и передернуть воркеров так?

нет, у воркеров нет поколений, поколения и потомки есть у мастер процесса, который един для обоих случаев

ага. потому я и сказал - ждать смерти воркеров

здравствуйте приехали, мастер процесс не будет ждать пока убьются все воркеры, он их рестартит не дожидаясь падения ВСЕХ старых воркеров

Неправда (если речь об nginx).

ладно. возможно, я не так понял задачу и даю не то решение

ладно. возможно, я не так понял задачу и даю не то решение

все равно спасибо

Неправда (если речь об nginx).

а ты попробуй сделать подряд несколько релоадов при long live connecions

Делал, и не раз. Твоё утверждение ложно.