Category: it

Как всегда, загадочные грабельки. Нынче в Линуксе

Почему-то в ноутбуке ping перестал работать:

$ ping 192.168.1.15
ping: socket: Operation not permitted

Хотя от root’а и просто через sudo вполне работал. И с другой машины в этой сети вполне работал из моего account’а, не только от root. И даже со смартфона, зайдя в его консоль через JuiceSSH, тоже вполне работало.

Погуглил, нашёл вот такую команду, и после её выполнения (от root’а), ping стал нормально работать и от меня:

# setcap cap_net_raw=ep /bin/ping

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)

Как обычно, загадочные грабельки, нынче в Debian’е на моём ноутбуке

Имеется линукс совершенно одинаковой версии (Debian 9.8) на внутреннем диске ноутбука, и на внешнем USB-диске.
Так с внутреннего диска vlc продолжал успешно проигрывать фильмы формата .ts, записанные со спутникового телевидения, а с внешнего пару дней назад почему-то перестал..
Хотя на обоих дисках я периодически обновляю все установленные пакеты, запуская “apt-get update; apt-get dist-upgrade”, и сейчас ещё раз это сделал, и хотя версии всех установленных пакетов были одинаковые, но на внутреннем диске vlc продолжал работать, а на внешнем продолжал не работать..

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

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)

Сегодня случились грабельки с SSL-сертификатом на моём веб-сайте

Утром посмотрел на свой предыдущий пост в LJ, опубликованный вчера, а там почему-то картинка пропала. Зашёл в Edit, там url картинки не поменялся. А когда попробовал посмотреть саму эту картинку, firefox сказал, что небезопасно.. Оказалось, что SSLный сертификат на моём веб-сайте сегодня рано утром закончился.

Хотя у меня там в cron приделана команда “certbot-auto renew” для обновления сертификата, выданного Let’s Encrypt, и раньше она успешно работала, а сегодня почему-то нет.
Попробовал запустить эту команду вручную, но она ругнулась на ошибочный код возврата команды “python -m pip –version”, и до обновления сертификата так и не дошла.
Типа, питон не может запустить модуль pip, потому оно и не работает.
Скачал этот скрипт certbot-auto заново с certbot.eff.org, но он точно такой же, ничего не менялось.

Погуглил, оказалось, в нём стОит заменить “python -m pip –version” на “pip –version”, и далее “python -m pip install –no-index –no-deps -U” заменить на “pip install –no-index –no-deps -U”.
Заменил, и тогда “certbot-auto renew” сработал, успешно обновив сертификат на очередные 3 месяца.

Но отчего такое могло случиться – не понимаю, раньше же этот скрипт успешно обновлял сертификат. А в старом Debian 7 (wheezy) уже давно ничего не обновляется, так что и питон не мог поменяться.

Потом ещё посмотрел на свой домашний сервер, где всё ещё использую тот же Debian 7, и оказалось, что и там сертификат не обновляется из-за такой же ошибки. Подправил и там certbot-auto точно так же, и он тоже стал работать.

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)

Многие уроды

почему-то используют мои адреса из Яндексовской и Гугловой электронной почты, регистрируясь на разнобразных веб-сайтах, или просто оформляя там заказы.

Хотя в Яндексе мой адрес просто @yandex.ru, но к нему автоматически добавлены алиасы с тем же именем в доменах @ya.ru, @yandex.com, @yandex.by, @yandex.ua, @yandex.kz.
А в Гугле у меня в имени используется точка, и там автоматически добавлен алиас с тем же доменом @gmail.com, но с именем без этой точки.
И вот почти все эти адреса используют уроды из многочисленных стран – из Индии, Индонезии, Японии, США, Бразилии, Португалии, России, и т.д.

И почему-то на многих веб-сайтах даже не просто на отдельные заказы, а конкретно на создание учётных записей, эти адреса добавляются автоматически, без отправки запросов на подтверждение от владельца адреса, и без получения этого подтверждения от меня. От некоторых запрсы приходят, и я их, естественно, не подтверждаю, но это довольно редко.
Так что приходится многократно рассылать сообщения о том, что я у них никогда не регистрировался, ничего не заказывал, поэтому прошу удалить учётные записи этих уродских пользователей и перестать присылать письма на мой адрес.

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

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)

Как всегда, загадочные грабельки. В линуксе

На работе меня попросили установить свежую версию astyle на несколько виртуальных машин.
Они все с CentOS, но готового пакета для них не нашёл, поэтому скачал исходники и попробовал скомпилировать вручную. На одной машине, где был CentOS 7, этот astyle вполне нормально скомпилировался и поставился.
А на остальных, где были разные версии CentOS 5 и 6, и уже были установлены старые версии astyle, свежая версия не скомпилировалось. Какие-то идиотские ошибки вылезали – типа, неправильный код во многих заголовочных файлах..

Ну, решил, что, может, имеет смысл скопировать уже готовый astyle с той CentOS7. Скопировал, но он не запускался. ldd показал неподходящие библиотеки. В частности, /lib64/libc.so.6 . Посмотрел, оказалось, что это не сама библиотека, а просто ссылка на libc-2.12.so . А на той машине, где astyle работал, это была ссылка на libc-2.17.so .

Решил приделать этот libc-2.17.so. Скопировал и эту библиотеку, но при попытке переделать ссылку на неё, наступил на основательные грабли:
удалил libc.so.6, чтобы приделать его ссылкой на новую библиотеку, но тут ln перестал работать.. А также и ls, и куча других программ тоже. Оказалось, что им всем нужен тот /lib64/libc.so.6 .

Да как же можно приделать обратно ссылку, если ж сам ln не работает??
Хорошо, что я не отключился от той машины, а то ведь туда и ssh перестал работать, потому что для sshd тоже нужен этот же libc.so.6 .

Погуглил, оказалось, что вот так можно запустить ln:

LD_PRELOAD=/lib64/libc-2.12.so ln -s libc-2.12.so libc.so.6

Это действительно сработало, так вот и удалось обойти эти грабельки..

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)

Идиотский сервер mariadb в свежем Debian’е

В Debian’е 9.6 попробовал установить mysql, но вместо него поставилась mariadb.

Сервер автоматически запустился, но зайти в него от меня самого не получалось:

$ mysql -u root
ERROR 1698 (28000): Access denied for user 'root'@'localhost'

А с “-p” запрашивался пароль, но я его не знал – при установке сервера пароль ввести не просили.

Погуглил, запустил от рута mysql_secure_installation, ввёл там пароль, но клиентскую программу всё равно не пускали:

$ mysql -u root -p
Enter password: 
ERROR 1698 (28000): Access denied for user 'root'@'localhost'

А вот когда попробовал запустить mysql от рута, он успешно подключился к серверу вообще без пароля:

# mysql
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 1
Server version: 10.1.37-MariaDB-0+deb9u1 Debian 9.6

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>

Посмотрел в таблицу mysql.user, там вполне был root@localhost с паролем и полными привилегиями, как обычно.

Ещё погуглил, и запустил там

GRANT ALL PRIVILEGES on *.* to 'root'@'localhost' IDENTIFIED BY 'ТОТжеСАМЫЙпароль';
FLUSH PRIVELEGES;

и хотя в mysql.user вроде ничего не поменялось, но “mysql -u root -p” стал работать от моего эккаунта.
А от рута просто так работать перестал:

# mysql 
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

Только с -p, и с тем же паролем работает, как обычно в mysql’е.

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)

Как обычно, загадочные грабельки. На этот раз – в MySQL’е

Сегодня на одной машине с MySQL-сервером файловая система оказалась забита более 90%..
Зашёл туда, проверил, и оказалось, что почти всё место занято самим MySQL’ем – в директории /var/lib/mysql/ .
Но не просто базой данных, а binlog’ами. Их буквально за сегодня собралось слишком много, и каждый больше гигабайта..

В /etc/my.cnf удаление binlog’ов сконфигурировано через 5 дней:

expire_logs_days=5

Решил удалить все ненужные файлы, но, типа, это не рекомендуется делать вручную в файловой системе, а предлагается удалять из самого MySQL командой

PURGE BINARY LOGS TO 'файл_до_которого_удалить';

Проверил, который из этих файлов используется сейчас самим master-сервером, и какие ещё считываются с него slave-серверами. Везде оказался один и тот же файл, и тогда все прежние я удалил. Теперь в файловой системе занято всего 27%. Выходит, что сама база данных не сильно большая, но почему-то очень много непростых операций сегодня над ней производили..

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)

А что, в России теперь не просто блокируют доступ к запрещённым сайтам,

а ещё и подсовывают для них поддельные IP-адреса через DNS?

Будучи в Москве, и подключившись к местному интернету, я запустил браузер в своём ноутбуке, и некоторые сайты оказались недоступны.
В частности, linkedin:

Ну, хотя этот сайт действительно запрещён Роскомнадзором, но IP-адреса в списке запретов совершенно другие, этого там нет:

Он оказался у российского интернет-провайдера:

И совершенно недоступный:

Collapse )

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)

Как обычно, загадочные грабельки. Нынче в линуксе

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

Я залогинился на тот сервер, посмотрел в shadow, а там ихних паролей вовсе нету. Оказалось, что они туда раньше заходили вообще без паролей, а просто с ssh’ными ключами.
А вот maximum password age, который в линуксе обычно устанавливается на 99999 дней (:0:99999:7:::), там почему-то был всего на 90 дней с предупреждениями за 7 дней до конца. Видимо, потому система и стала их просить поменять пароли, но их там не было, потому и не удавалось:
user_login:!!:17742:1:90:7:90::

Ну, я там всё подправил, но отчего там у всех поменялись эти настройки – не понимаю..

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)

Уродский зашифрованный zip из винды

При попытке распаковать его в линуксе unzip’ом создались только директории, но в них ни одного файла.
unzip вовсе не спрашивал пароля, а про все файлы ругался: “unsupported compression method 99″.

При попытке указать пароль вручную:

unzip -P password file.zip

ничего не изменилось – директории создались, а файлы нет.

И только погуглив, я узнал, что такой файл можно распаковать 7zip’ом:

7z x -ppassword file.zip

Вот оставлю себе на память эту команду, если опять встретится такой уродский файл.

Оригинал этой записи в личном блоге.

(comment count unavailable | Комментировать в Dreamwidth)