Есть у меня на одном офисе Mikrotik Rb951ui-2hnd, ему уже лет 10 наверное (может из-за этого?), работает он в тепличных условиях, нагрузка совсем небольшая. В этом году он уже раза три сделал странное - перезагрузился вместе со сбросом конфигурации к стандартной. Сперва я подумал что его сломали - но один раз он этот финт провернул прямо у меня в "руках", в общем я его обновил до 6.45.7 stable, поменял пароли (это было летом), а неделю назад он опять сбросился. Бед-блоков на флешке нет, чего-то другого подозрительного тоже нет.

Что посмотреть, куда покопать?

https://ru-root.livejournal.com/2925594.html

Парни, а как в openldap создать следующее
есть супергруппа monitoring
в ней подгруппы zabix, garafana, prometeus

если вносить в monitoring
member: cn=Alexander Titaev,ou=people,dc=test,dc=local

это членство автоматично распространялось на подгруппы

попробовал через создание

dn: cn=dyngroup,ou=groups,dc=test,dc=local
objectClass: groupOfURLs
cn: dyngroup
memberURL: ldap:///ou=groups,dc=test,dc=local?cn,sn?one?(cn=dyn*)

и обломался, тк в ней
attribute 'member' not allowed

https://ru-root.livejournal.com/2925550.html

Доброго времени суток!

Кто-нибудь что-нибудь понимает во freebsd'шном devd (Фря 11)?
Втыкаю девайс, который ловится по device-name uftdi0.
Правило, создающее симлинку, отрабатывает, но симлинка ведет вникуда, девайс uftdi0 исчезает, вместо него появляется комплект из cuaU0 и ttyU0 со товарищи. Из них нужен cuaU0, но это не device-name, а cdev.

Курение лога devd не спасло.

Собственно, вопросов два - кто изничтожает /dev/uftdi0 и создает пару из /dev/cuaU0 и /dev/ttyU0, и как автоматически создавать симлинку на /dev/cuaU0, как ее ловить.

https://ru-root.livejournal.com/2925146.html

Внезапно, у кого-нибудь под рукой есть сабжевое устройство (усб-сетевушка)?
именно сабжевое, не rndis, не вендор класс/модель, а именно cdc eem?

если есть, киньте в камменты что про нее говорит "lsusb -vvv"

заранее спасибо!

ps: хочу реализовать подобное на базе stm32f4discovery+libopencm3, по свободной лицензии. себе для потенциальной коммерческой выгоды и окружающим за просто так.

https://ru-root.livejournal.com/2924981.html

гайзы, а может кто интегрил gitlab c ldap over ssl?

в том yaml что идет как образец в контексте ldap есть verify_certificates

[root@gitlab-new ~]# grep -B20 verify_cer /opt/gitlab/embedded/service/gitlab-rails/config/gitlab.yml.example | grep -v \#

bind_dn: '_the_full_dn_of_the_user_you_will_bind_with'
password: '_the_password_of_the_bind_user'

encryption: 'plain'

verify_certificates: true

если вписывать аналогичное в
[root@gitlab-new ~]# grep verify_certific /etc/gitlab/gitlab.rb
gitlab_rails['verify_certificates'] = false
gitlab_rails['ldap_verify_certificates'] = false
[root@gitlab-new ~]#

и потом гонять
gitlab-ctl reconfigre

то в конечном gitlab.yml про это ни слова
[root@gitlab-new ~]# grep verify_certific /var/opt/gitlab/gitlab-rails/etc/gitlab.yml
[root@gitlab-new ~]#

при этом в коде оно выглядит вот так

[root@gitlab-new ~]# grep -B5 -A5 verify_certifica /opt/gitlab/embedded/service/gitlab-rails/lib/gitlab/auth/ldap/config.rb
opts = base_options.merge(
base: base,
encryption: options['encryption'],
filter: omniauth_user_filter,
name_proc: name_proc,
disable_verify_certificates: !options['verify_certificates'],
tls_options: tls_options
)

if has_auth?
opts.merge!(
--
return @tls_options if defined?(@tls_options)

method = translate_method
return unless method

opts = if options['verify_certificates'] && method != 'plain'
# Dup so we don't accidentally overwrite the constant
OpenSSL::SSL::SSLContext::DEFAULT_PARAMS.dup
else
# It is important to explicitly set verify_mode for two reasons:
# 1. The behavior of OpenSSL is undefined when verify_mode is not set.
[root@gitlab-new ~]#


я в затруднении как оно должно быть по фэньшую...

ps.
gitlab-ce.x86_64 12.2.4-ce.0.el7 installed

https://ru-root.livejournal.com/2924656.html

столкнулся со странным. Пересаживаю jenkins c ds389 на openldap. Не идет аутентификация


Nov 15 10:57:04 openldap slapd[1391]: conn=1102 fd=24 ACCEPT from IP=10.0.2.14:39810 (IP=0.0.0.0:389)
Nov 15 10:57:04 openldap slapd[1391]: conn=1102 op=0 BIND dn="cn=Alexander Titaev,ou=people,dc=test,dc=local" method=128
Nov 15 10:57:04 openldap slapd[1391]: conn=1102 op=0 BIND dn="cn=Alexander Titaev,ou=people,dc=test,dc=local" mech=SIMPLE ssf=0
Nov 15 10:57:04 openldap slapd[1391]: conn=1102 op=0 RESULT tag=97 err=0 text=
Nov 15 10:57:04 openldap slapd[1391]: conn=1102 op=1 SRCH base="cn=Alexander Titaev,ou=people,dc=test,dc=local" scope=0 deref=3 filter="(objectClass=*)"
Nov 15 10:57:04 openldap slapd[1391]: conn=1102 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
Nov 15 10:57:04 openldap slapd[1391]: conn=1102 op=2 UNBIND
Nov 15 10:57:04 openldap slapd[1391]: conn=1102 fd=24 closed


через binduser залогиниться можно. Для binduser было сделано следующее


dn: olcDatabase={2}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to attrs=userPassword
by dn="cn=binduser,ou=people,dc=test,dc=local" auth
by self write
by anonymous auth
by * none

dn: olcDatabase={2}hdb,cn=config
changetype: modify
add: olcAccess
olcAccess: to *
by dn="cn=binduser,ou=people,dc=test,dc=local" read
by users read
by * none


и как-то я в затруднении какую acl нужно вписать

https://ru-root.livejournal.com/2924288.html

а там все по прежнему, через патч и пересборку?

https://ru-root.livejournal.com/2924259.html

На хостинге есть веб-сервер под IIS, обслуживающий сайт по HTTPS с относительно тяжелым мультимедиа-содержимым (система обучения). Есть локальная сеть в географически удалённом месте с не очень быстрым интернет-каналом и учебным классом со "студентами". Мультимедиа-контент в основном статика и для ускорения работы его можно было бы принудительно кешировать, для чего на стороне клиентов был в качестве эксперимента установлен Apache 2.4.41 с засунутым в него сертификатом/приватным ключом с оригинального сервера и mod_proxy+mod_cache для реверс-проксирования с кешированием. И оно даже заработало, в кеше стали оседать файлы с JS-кодом и всякие картиночки PNG.

Но оказалось, что JS-код на стороне клиентов загружает мультимедию кусочками, так что прокси получает от сервера ответы 206 Partial Content вместо 200 OK. И ещё оказалось, что апачевские модули mod_cache_disk и socache не поддерживают кеширование данных из таких ответов.

Раньше Squid либо тоже не кешировал 206, либо в таком случае загружал с сервера файл целиком (и тогда кешировал), в зависимости от того, насколько много лишнего ему приходилось качать, предел задавался в конфиге - решение "очень среднее", лекарство может выйти хуже болезни. Притом, что если клиент обрывает загрузку, то и Squid её тоже обрывает, а значит, не кеширует.

Вопрос: какой софт умеет эффективно кешировать такие ответы и работать реверс-проксей? Nginx? Varnish? Что-то ещё?

https://ru-root.livejournal.com/2923903.html

Доброго дня

Помогите пожалуйста решить задачку.

Есть Cisco роутер. Есть микротик роутер.

В циску приходит на один интерфейс из вне 2 vlan-а.
Назовём их номер 1 и номер 600
Нужно каким то мистическим способом сделать так, чтобы этот 600 vlan транслировался на микротик и с микротика дальше.
Как бы это организовать по-правильному?

x-post ru_sysadmin

https://ru-root.livejournal.com/2923523.html

есть почтовая система с кучей аккаунтов на древней fbsd9, есть желание унести ее на cent7. Но пароли криптованы blowfish

vk:$2a$04$nSyCA9Fmlozg34C9vSJqcuOAx/oTTc6oo8nRMS46NqTbkHEopo.22:...

что-то я глянул гугла и в непонятках, с одной стороны вроде как оно поддерживается путем установки для pam библиотек от susi. Но будет ли работать с таким dovecot/exim если их тыкать напрямую в файл с таким паролем?


update:
BLF-CRYPT: This is the Blowfish crypt (bcrypt) scheme. It is generally considered to be very secure. The encrypted password will start with $2y$ (other generators can generate passwords that have other letters after $2, those should work too.)

Note
v2.2: bcrypt is not available on most Linux distributions). Since v2.3.0 this is provided by dovecot. You can tune the computational cost using -r parameter for doveadm.

осталось найти dovecot 2.3 под cent7

https://ru-root.livejournal.com/2923304.html

дано
gitlab-ee.x86_64 12.0.2-ee.0.el7
фронтендом
nginx.x86_64 100:1.17.3-1.p6.0.3.el7 @passenger

в гитлабе большая репа (почти 9Г)

при клонировании по https на той же машине где расположен гитлаб все работает

на соседней
remote: Enumerating objects: 86719, done.
remote: Counting objects: 100% (86719/86719), done.
remote: Compressing objects: 100% (71259/71259), done.
fatal: The remote end hung up unexpectedly0 GiB | 10.73 MiB/s
fatal: early EOF
fatal: index-pack failed

понятно что какой-то таймаут, но какой ?

вот это уже выкрутил
unicorn['worker_timeout'] = 600

ps. переход на ssh очевиден, но меня интересуют причины такой ситуации

https://ru-root.livejournal.com/2923096.html

# uname -a
Linux mail 3.10.0-514.6.1.el7.x86_64 #1 SMP Wed Jan 18 13:06:36 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
# netstat -etnlp | grep '\-'
Proto Recv-Q Send-Q Local Address Foreign Address State User Inode PID/Program name
tcp 0 0 0.0.0.0:29172 0.0.0.0:* LISTEN 0 77404 -
tcp6 0 0 :::26945 :::* LISTEN 0 77405 -
# telnet localhost 29172
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
sd
Connection closed by foreign host.
# telnet localhost 26945
Trying 127.0.0.1...
telnet: connect to address 127.0.0.1: Connection refused
Trying ::1...
telnet: connect to address ::1: No route to host

ну нет на машине ipv6

# lsof -i4tcp:29172
# lsof -i6tcp:26945
# find -inum 77404
# find -inum 77405
# ss -p | grep -w 29172
# lsof | grep -w 77404

в iptables только базовый INPUT

как понять кто слушает порт?

https://ru-root.livejournal.com/2922947.html

у клиента nginx проксирует запросы на tomcat. tomcat должен возвращать 301 с хитрым url, но у него регулярно затекает мозг и он периодически начинает возвращать 200. Помогает рестарт. Клиент просит временно, пока они разбираются с явой сделать перехват этих 200 с преобразованием в 301, подобного тому что делает tomcat, но по упрощенной схеме. Вот никак не соображу как этот перехват сделать.

для error_page 200 ессно ругань
nginx: [emerg] value "200" must be between 300 and 599

proxy_intercept_errors аналогично "с кодом больше либо равным 300"

https://ru-root.livejournal.com/2922708.html

Всем привет. После обновления Debian 7 -> 8 столкнулся с неработающим 3G модемом huawei, а именно - не создаются /dev/ttyUSB*.
Устройство видится в lsusb, для него есть правила udev, которые запускают usb_modeswitch и должно быть все хорошо, но нет.
откатился на libusb-0.1.4 usb_modeswitch и usb-modeswitch-data из 7-ки, но это тоже не помогло.
Нашел Mobile_Partner. Он ставит какой-то адовый драйвер, который показывает 3 устройства (приделывая к ним модуль usbserial_generic), в 7-ке без этого Mobile_Partner было 2.

[78866.687315] usb 1-4: USB disconnect, device number 20
[78866.984106] usb 1-4: new full-speed USB device number 21 using ohci-pci
[78867.159639] usb 1-4: New USB device found, idVendor=12d1, idProduct=1506
[78867.159648] usb 1-4: New USB device strings: Mfr=2, Product=1, SerialNumber=3
[78867.159652] usb 1-4: Product: HUAWEI MOBILE
[78867.159656] usb 1-4: Manufacturer: HUAWEI
[78867.159659] usb 1-4: SerialNumber: ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
[78867.164000] usbserial_generic 1-4:1.0: The "generic" usb-serial driver is only for testing and one-off prototypes.
[78867.164075] usbserial_generic 1-4:1.0: Tell linux-usb@vger.kernel.org to add your device to a proper driver.
[78867.164083] usbserial_generic 1-4:1.0: generic converter detected
[78867.165461] usb 1-4: generic converter now attached to ttyUSB0
[78867.166103] usbserial_generic 1-4:1.1: The "generic" usb-serial driver is only for testing and one-off prototypes.
[78867.166115] usbserial_generic 1-4:1.1: Tell linux-usb@vger.kernel.org to add your device to a proper driver.
[78867.166121] usbserial_generic 1-4:1.1: generic converter detected
[78867.168210] usb 1-4: generic converter now attached to ttyUSB1
[78867.168819] usbserial_generic 1-4:1.2: The "generic" usb-serial driver is only for testing and one-off prototypes.
[78867.168829] usbserial_generic 1-4:1.2: Tell linux-usb@vger.kernel.org to add your device to a proper driver.
[78867.168835] usbserial_generic 1-4:1.2: generic converter detected

но устройств как не было в /dev так и нет.
В итоге добился того, что устройство определяется с одним портом.

KERNEL[168404.827829] add /devices/pci0000:00/0000:00:0f.2/usb1/1-4 (usb)
KERNEL[168404.831033] add /devices/pci0000:00/0000:00:0f.2/usb1/1-4/1-4:1.0 (usb)
UDEV [168404.836235] add /devices/pci0000:00/0000:00:0f.2/usb1/1-4 (usb)
KERNEL[168405.865867] add /module/usbserial (module)
KERNEL[168405.867605] add /bus/usb-serial (bus)
UDEV [168405.868582] add /module/usbserial (module)
KERNEL[168405.871274] add /bus/usb/drivers/usbserial (drivers)
UDEV [168405.871414] add /bus/usb-serial (bus)
KERNEL[168405.871456] add /bus/usb/drivers/usbserial_generic (drivers)
KERNEL[168405.871492] add /bus/usb-serial/drivers/generic (drivers)
KERNEL[168405.871540] add /devices/pci0000:00/0000:00:0f.2/usb1/1-4/1-4:1.0/ttyUSB0 (usb-serial)
KERNEL[168405.872385] add /devices/pci0000:00/0000:00:0f.2/usb1/1-4/1-4:1.0/ttyUSB0/tty/ttyUSB0 (tty)
KERNEL[168405.874349] add /module/usb_wwan (module)
KERNEL[168405.877793] add /module/option (module)
KERNEL[168405.877983] add /bus/usb/drivers/option (drivers)
KERNEL[168405.878626] add /bus/usb-serial/drivers/option1 (drivers)
UDEV [168405.883224] add /devices/pci0000:00/0000:00:0f.2/usb1/1-4/1-4:1.0 (usb)
UDEV [168405.890142] add /bus/usb/drivers/usbserial (drivers)
UDEV [168405.893865] add /bus/usb/drivers/usbserial_generic (drivers)
UDEV [168405.901936] add /bus/usb-serial/drivers/generic (drivers)
UDEV [168405.910687] add /module/usb_wwan (module)
UDEV [168405.911702] add /devices/pci0000:00/0000:00:0f.2/usb1/1-4/1-4:1.0/ttyUSB0 (usb-serial)
UDEV [168405.917567] add /module/option (module)
UDEV [168405.930349] add /bus/usb/drivers/option (drivers)
UDEV [168405.939284] add /bus/usb-serial/drivers/option1 (drivers)
UDEV [168405.984553] add /devices/pci0000:00/0000:00:0f.2/usb1/1-4/1-4:1.0/ttyUSB0/tty/ttyUSB0 (tty)

#usb-devices
T: Bus=01 Lev=01 Prnt=01 Port=03 Cnt=02 Dev#= 32 Spd=12 MxCh= 0
D: Ver= 2.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=64 #Cfgs= 1
P: Vendor=12d1 ProdID=1506 Rev=00.01
S: Manufacturer=HUAWEI
S: Product=HUAWEI MOBILE
S: SerialNumber=ÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿÿ
C: #Ifs= 1 Cfg#= 1 Atr=80 MxPwr=500mA
I: If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=02 Prot=02 Driver=usbserial_generic


но у него опять драйвер usbserial_generic и при попытке подключения не происходит ничего. Из 3.16.0 ведра выкинули модем или что я делаю не так?
спасибо

https://ru-root.livejournal.com/2922494.html

Парни, я пытаюсь найти описание процедуры взаимодействия регистраторов и корневых серверов и ничего связного найти не могу. Ну кроме этого.
"Технические функции регистратора доменов состоят в поддержании базы данных зарегистрированных доменов, предоставлении всем желающим доступа к этой базе по протоколу whois, а также в поддержании DNS-сервера (серверов) соответствующей зоны с NS-записями для всех зарегистрированных доменов."
https://ru.wikipedia.org/wiki/Регистратор_доменных_имён

Проблема следующая, у клиента несколько тысяч доменов, для которых указаны на reg.ru
ns1.exmple.ru
ns2.exmple.ru
днс хостинг свой на hetzner, включая домен exmple.ru

потом dns хостинг exmple.ru, был унесен на claudflare. Сделано это было больше месяца назад. ip для
ns1.exmple.ru
ns2.exmple.ru
были изменены на адреса claudflare.

на регру для exmple.ru указаны
nserver: noah.ns.cloudflare.com.
nserver: uma.ns.cloudflare.com.

но до сих пор корневые серверы почему-то возвращают для всех этих доменов ip адреса ns1.exmple.ru/ns2.exmple.ru хетцеровские. В то время как они давно поменялись.

https://ru-root.livejournal.com/2922122.html

имеем судя по всему виндовый l2tp сервер за файрволом
согласно
https://blogs.technet.microsoft.com/rrasblog/2006/06/14/which-ports-to-unblock-for-vpn-traffic-to-pass-through/
он юзает
For L2TP:
IP Protocol Type=UDP, UDP Port Number=500 <- Used by IKEv1 (IPSec control path)
IP Protocol Type=UDP, UDP Port Number=4500 <- Used by IKEv1 (IPSec control path)
IP Protocol Type=ESP (value 50) <- Used by IPSec data path

из винды цепляюсь без проблем. И как показывает tcpdump никакого 1701/udp там не бегает. Но мне нужно подцепить туда linux. И вот тут я туплю, тк xl2tpd знать ничего не хочет про 4500, даже если я явно указываю

[global]
port = 4500

как клиент он ломит на 1701. Может кто разруливал подобное?

https://ru-root.livejournal.com/2921758.html

на fbsd strongswan как клиент (IKEV2 EAP_MSCHAPV2)
облом на этапе создания tun0

installing new virtual IP 10.0.42.3
created TUN device: tun0
virtual IP 10.0.42.3 did not appear on tun0
installing virtual IP 10.0.42.3 failed

это те же грабли?
https://wiki.strongswan.org/issues/566

у кого-нибудь работает?

ps.
root@fbsdap:~ # pkg info | grep stron
strongswan-5.8.0 Open Source IKEv2 IPsec-based VPN solution
root@fbsdap:~ # uname -a
FreeBSD fbsdap 11.2-RELEASE-p10 FreeBSD 11.2-RELEASE-p10 #0: Mon May 13 21:20:50 UTC 2019 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64

https://ru-root.livejournal.com/2921587.html

Давно уже использовал у себя cyrus в качестве Pop3 и Imap-сервера. А сейчас обновил Debian с 7 версии на 8, и почему-то случилась серьёзная ошибка:

Пока cyrus не запущен, sendmail принимает письма на местные адреса, и держит их у себя, указывая в логе, что "Could not connect to socket /var/run/cyrus/socket/lmtp". То есть, эти адреса считаются нормальными.

А когда включаю cyrus, sendmail пишет "stat=User unknown", и отправляет обратно письма о том, что эти адреса не существуют.

Хотя, запуская listmailbox в cyradm, все эти адреса вполне вижу. И пользователи успешно подключаются к этому Pop3/Imap, используя эти свои адреса.

Есть у кого идеи, отчего такое могло случиться, и как это можно исправить, чтобы письма успешно доставлялись в cyrus?

UPD: похоже, при обновлении пакетов при обновлении Debian'а что-то дефектное случилось в sendmail.cf . Я его сейчас переделал, просто запустив build.sh в /etc/mail/ , и после перезапуска sendmail'а с этим новым sendmail.cf (который оказался довольно меньше прежнего - 67K вместо 81K), вроде всё стало нормально работать - письма теперь успешно доставляются в /var/spool/cyrus/mail/...

https://ru-root.livejournal.com/2921349.html

приветствую!

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

а именно, как создать систему хранения которая бы решала задачи, стоящие перед некоторыми из нас по части реализации закона яровой? ведь что нам надо получить по итогу:
1. запись со скоростью снимаемого потока информации
2. абсолютно неважна скорость чтения
3. под большим вопросом необходимость дупликации информации, но скорее да чем нет
4. возможность добавлять объем хранилища на лету
5. возможность замены вылетевших дисков
6. цена = стоимость дисков + стоимость необходмого железа
7. сложность создания и настройки системы не нормируется

архитектура системы, которая первая приходит в голову, будет таковой:
1. съемники потока, к которым подключено хранилище. тут сразу желательно разбивать поток на какие-то блоки, напрашивается разбивка по netflow. должны быть легко добавляемы. возможно, между устройствами, шлющими (интересное слово) потоки и съемниками должен стоять какой-то диспетчер, но может быть и нет. (*nix)
2. ядра хранения, должны быть заменяемы, собирают сеть в хранилище (*nix)
3. сеть хранения, состоящая из серверов, контроллеров и дисков, цена железа должна быть минимальной, диски самыми дешевыми.

пока не придумывается ничего лучше чем отдавать каждый диск с железок (3) по iscsi, собирать из них одну большую хранилку на ZFS на ядрах (2), и раздавать её nfsv4 съемникам (1).

есть более светлые мысли?

https://ru-root.livejournal.com/2921168.html

Хотя VPN - это virtual PRIVATE network, но я знаю, что в IPSec можно использовать не только приватные, но и публичные IP-адреса.
А можно ли как-то сконфигурировать через IPSec (или через OpenVPN) доступ ко всем публичным адресам, чтобы через этот туннель можно было соединяться не только с внутренними машинами, а и выходить в интернет наружу, куда угодно?

https://ru-root.livejournal.com/2920927.html