![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
На работе меня попросили установить свежую версию 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
Это действительно сработало, так вот и удалось обойти эти грабельки..
Оригинал этой записи в личном блоге.
Внезапно у нашей компании обнаружился клиент с таким названием.
Я очень удивился, но оказалось, что это вовсе не то, о чём я подумал, а Financial Services Board (департамент финансовых услуг) в Южно-Африканской Республике..
Оригинал этой записи в личном блоге.
Сегодня ночью мне приснилось, что зайдя в аптеку, я увидел там рекламное объявление, что их компания ищет работника для работы в онлайне.
Сфотографировал это объявление своим смартфоном, а когда дома смотрел на эту фотографию, обнаружил, что у меня там есть ещё одна фотография аналогичного объявления из какого-то другого магазина.
Типа, и там, и там, предлагали работать из дома через интернет. Меня это вполне устраивало, и я решил узнать, какие зарплаты они предлагают за эти работы. Если как на моей нынешней работе или побольше, то я вполне могу к ним перейти.
Но что из этого получилось – не знаю, я тут уже проснулся.
И хотя потом увидел ещё один сон, где я на свойм ноутбуке редактировал какие-то файлы с программами или с исходными кодами каких-то веб-страниц, связанные с предложениями тех компаний, но почему-то после сохранения не мог найти этих файлов. Показал это своей жене, видимо, решив спросить, не знает ли она, куда эти файлы могли сохраниться. Но тут опять проснулся.
Оригинал этой записи в личном блоге.
Три дня назад на работе организовали рождественскую вечеринку. Но не в самом офисе, а в паре пабов.
И один из них – Teeling Distillery – оказался не просто пабом, а ещё и заводом по производству виски, и там случилась экскурсию по этому заводу..
Такие вот огромные устройства используются там для производства виски:
Оригинал этой записи в личном блоге.
Один коллега на работе попросил у меня пароль к офисной WiFi-сети. Я ему выдал, но он сказал, что не подходит, хотя раньше вроде работал, и дома у него WiFi на телефоне тоже успешно работает.
Я попробовал сам ввести этот пароль на его iPhone пару раз, но при попытке соединиться этот уродский айфон продолжал сообщать, что пароль неправильный.
На всякий случай я решил проверить пароль на своём андроидном смартфоне. Хотя он вроде уже был успешно соединён, но я указал ему забыть эту сеть, и соединился заново, введя тот же самый пароль, и он успешно сработал. А на том айфоне этот пароль почему-то продолжал считаться неправильным. Попробовал соединить его с гостевой WiFi сетью, и тамошний пароль сработал.
Выходит, на этом айфоне действительно уродская система, которая почему-то некоторые пароли не может использовать.
Так что, пожалуй, я правильно не люблю Apple’овские устройства, кривые они.
Оригинал этой записи в личном блоге.
Сегодня на одной машине с MySQL-сервером файловая система оказалась забита более 90%..
Зашёл туда, проверил, и оказалось, что почти всё место занято самим MySQL’ем – в директории /var/lib/mysql/ .
Но не просто базой данных, а binlog’ами. Их буквально за сегодня собралось слишком много, и каждый больше гигабайта..
В /etc/my.cnf удаление binlog’ов сконфигурировано через 5 дней:
expire_logs_days=5
Решил удалить все ненужные файлы, но, типа, это не рекомендуется делать вручную в файловой системе, а предлагается удалять из самого MySQL командой
PURGE BINARY LOGS TO 'файл_до_которого_удалить';
Проверил, который из этих файлов используется сейчас самим master-сервером, и какие ещё считываются с него slave-серверами. Везде оказался один и тот же файл, и тогда все прежние я удалил. Теперь в файловой системе занято всего 27%. Выходит, что сама база данных не сильно большая, но почему-то очень много непростых операций сегодня над ней производили..
Оригинал этой записи в личном блоге.
Этот список вопросов был составлен моим прежним начальником – афроадминистратором (в смысле, он был из Южной Африки).
Эти вопросы вполне приемлемы для новых системных администраторов в нашей компании. Хотя их уже давно не принимали, и даже не искали, если только не считать моего нового начальника, который заменил прежнего.
И для меня сейчас эти вопросы оказались полезны, а то я слова забываю, но вот отсюда их вполне вспомнил. Ну и ответы в целом вполне знаю.
Если кому интересно, смотрите все эти вопросы под катом:
Оригинал этой записи в личном блоге.
Пара сотрудников на работе пожаловались, что не могут залогиниться на один сервер по ssh. Он постоянно требует поменять пароли, а они тамошних паролей толком не помнят. Пробовали все, которые обычно используют, но не сработало.
Я залогинился на тот сервер, посмотрел в shadow, а там ихних паролей вовсе нету. Оказалось, что они туда раньше заходили вообще без паролей, а просто с ssh’ными ключами.
А вот maximum password age, который в линуксе обычно устанавливается на 99999 дней (:0:99999:7:::), там почему-то был всего на 90 дней с предупреждениями за 7 дней до конца. Видимо, потому система и стала их просить поменять пароли, но их там не было, потому и не удавалось:
user_login:!!:17742:1:90:7:90::
Ну, я там всё подправил, но отчего там у всех поменялись эти настройки – не понимаю..
Оригинал этой записи в личном блоге.
8-800-***-**** – они бесплатные для звонков изнутри России.
А вот всегда ли на них можно дозвониться из-за границы в виде +7-800-***-**** ? Или это должно специально устанавливаться на каждый конкретный номер?
Оригинал этой записи в личном блоге.
А потом тот же африканский сотрудник попросил зарегистрировать ещё один домен в .co.mw. Ну, я попробовал на marcaria.com, где мы обычно регистрируем африканские домены, регистратор деньги за него взял, но написал, что домен ещё только в процессе регистрации, и этот процесс может занять до 30 дней..
Видимо, это передача данных владельцу самогО домена co.mw, и получение одобрения от него может быть такое долгое..
Upd: через час регистратор уже показывает домен зарегистрированным, но авторизованные NS-сервера co.mw его ещё вовсе не показывают..
Upd2: а ещё примерно через час в DNS-серверах уже всё нормально стало.
Оригинал этой записи в личном блоге.
Вчера один африканский сотрудник нашей компании попросил добавить тамошний домен ***.co.mw в качестве алиаса к нашему основному домену, используемому в гуглопочте, чтобы всем тамошним сотрудникам можно было писать письма на тот домен, и они бы их автоматически получали.
Ну, я его в гуглопочту вполне легко добавил. И проверил, послав письмо самому себе на тот ***.co.mw со своего личного адреса, и это письмо успешно получил на свой стандартный рабочий адрес.
А вот всем остальным на адреса в том домене письма почему-то не доходили.. Сама гуглопочта присылала ответы
“Address not found
Your message wasn’t delivered to ***@***.co.mw because the address couldn’t be found, or is unable to receive mail.”
Оказалось, что появление этих адресов может занимать целые сутки.. https://support.google.com/domains/answer/6304395:
“For domain aliases, it can take up to 24 hours after verification for all users to receive their alias email addresses.”
Но мой-то адрес сразу сработал.. А остальные продолжали не работать, постоянно выдавая точно такие же отказы на следующие проверочные письма.
Хотя через 24 часа они и вправду заработали, но отчего же это так долго?
Оригинал этой записи в личном блоге.
Вчера на работе создал очередную виртуальную машинку на CentOS для веб-сайта. Но апач почему-то не запускался..
В /var/log/httpd/error_log писал, что не может открыть лог-файл в другой директории, которая была указана в его конфигурации.
Посмотрел – директория на месте, файлы там создавать вполне можно. И хотя у апача User и Group apache, но запускается-то он от рута, и логи создаёт им же. Вот хотя бы у того же /var/log/httpd/error_log – root:root. На всякий случай попробовал поменять владельца той директории на apache:apache, но ничего не изменилось.
Оригинал этой записи в личном блоге.
опять встретил загадочные грабельки..
С большинства серверов всё нормально копировалось, а с трёх почему-то
failed: Permission denied (13) ..
Хотя на всех серверах доступ к /var/log/ сконфигурирован одинаково:
[varlog]
uid = root
gid = root
path = /var/log
hosts allow = IP-адрес клиентского хоста
но вот почему-то Permission denied..
Попробовал rsync --list-only server-name::varlog/ , так увиделась ещё более странная фигня: некоторые файлы и директории видны, а большинство таки нет. Хотя практически у всех них пользователь и группа root:root, но по-любому root должен видеть всё, ан нет:
Оригинал этой записи в личном блоге.
Сегодня на работе писал скрипт для копирования файлов rsync’ом с нескольких серверов на бэкапный. И хотя на них всех rsyncd установлен, нормально сконфигурирован, доступ к 873 порту местными файрволами разрешён, но при попытке зайти туда rsync’ом с бэкапного сервера почему-то везде спрашивали пароль..
Погуглил, оказывается, теперь rsync по умолчанию использует ssh (раньше это надо было специально указывать параметром -e ssh), а как теперь напрямую присоединиться к rsyncd – не нашёл.
И только заглянув в аналогичный скрипт, написанный системным администратором из Восточной Африки (Кении), обнаружил, что достаточно после имени хоста написать два двоеточия: rsync -параметры hostname::src /dst/, и тогда он цепляется напрямую к rsyncd.
Оригинал этой записи в личном блоге.
На работе один разработчик удалял ненужные старые базы данных на MySQL master-сервере. А внезапно slave перестал работать, типа, не смог у себя удалить одну из тех баз:
Error was = Error 'Error dropping database (can't rmdir './название_базы/', errno: 17)' on query. Default database: ''. Query: 'drop database название_базы'
Я пошёл копать, оказалось, что MySQL не делает rm -rf на директорию от удаляемой базы. Он уже удалил свои стандартные файлы с данными и индексами, а потом пытался удалить директорию, но это не сработало, потому что в директории оказались лишние файлы: какие-то 20051114_outgoing.TMD_backup и 20051115_outgoing.TMD_backup. Ну я их удалил вручную, перезапустил slave, и тогда drop database сработал.
Потом такая же фигня случилась на паре других баз данных, пришлось опять удалять лишние файлы вручную. А потом ещё и на master-сервере одна база не удалилась по той же причине, и там пришлось вручную удалить лишний файл *.TMD_backup.
Что это за файлы, и откуда они взялись – совершенно не понимаю. Пробовал погуглить, но тоже не нашёл.
Оригинал этой записи в личном блоге.
Помнится, раньше для этого в основном использовался IRC.
Нынче для общения внутри компаний популярен slack. Он действительно довольно удобный, там можно не только текстовые сообщения отправлять, а и картинки, и прочие файлы, но за него надо платить. Особенно чтобы история сохранялась, а то она там виднеется только за пару недель, а чтобы подольше – надо дополнительно платить.
А теперь нашёлся rocket.chat, который по функциональности практически как slack, но его сервер можно установить у себя за бесплатно, и подключаться к нему браузерами или приложениями с компьютера и со смартфона. Каналы на этом сервере можно организовывать общие, куда могут заходить все желающие, или частные, куда можно добавлять нужных людей вручную. И переписка там может быть кодированная, чтобы никто снаружи не подсмотрел.
Сейчас у меня на работе его начали использовать, и я подумал, а не поставить ли мне его у себя на сервере для общения со своими родственниками и знакомыми?
Оригинал этой записи в личном блоге.
Да нифига! Они у нас в компании и тут работают, и в Англии, и никаких проблем не вызывают.
А основные дефекты у меня на работе почему-то провоцируются африканцами. В смысле, вовсе не неграми, а просто живущими в Африке. Там и белых нынче немало.
Вот, например, выдали мне задачу организовать там VPN с одним клиентом. Казалось бы, ничего сложного тут нет. Они прислали форму со всеми параметрами, я всё сконфигурировал, переслал им через тамошнего нашего сотрудника PSK (ключ для шифрования), но этот VPN больше месяца не удавалось включить. Обсуждали это с ними в онлайновом чате, я просил проверить ихние настройки, они просили прислать скриншоты настройки VPNа с нашей стороны, но ничего не помогло. В конце концов выяснилось, что они у себя почему-то установили совершенно другой ключ. И когда его прислали, и я его подправил, и VPN таки заработал.
Или вот сейчас там один сервер стал дико тормозить. Тамошний сотрудник решил, что туда слишком много запросов приходит, и попросил меня заблокировать доступ к тамошнему апачу со всех IP, разрешить только с одного. Ну, я на firewall’е это быстро сделал, а он пожаловался, что после redirect’а с того IP, он не может попасть на веб-сайт. Ну, естественно, доступ же заблокирован.
Оказалось, что он на самом деле хотел разрешить запросы не с самого этого IP, а со ссылками с тамошнего веб-сервера. То есть, referer в запросах проверять надо, а вовсе не IP-адрес клиентского браузера.
А теперь ещё просит меня сконфигурировать на том сервере несколько экземпляров apache. А нафига это там может понадобиться, толком объяснить не может.
Выходит, что термин “афрадминистраторы” не просто так придуман, а имеет реальные основания..
Оригинал этой записи в личном блоге.
Сегодня попробовал поработать из дома, а VPN в офис почему-то отвалился. В прошлую пятницу такое же было, пришлось туда поехать, оказалось, что тамошний маршрутизатор почему-то выключился, и в офисной сети интернет отвалился. Ну так я его включил, всё наладилось. А сегодня поехать не получилось. Автобусы опять не работали:
Решил поехать на машине, но не смог отъехать от дома, всё вокруг было слишком забито снегом, и местами он превращался в лёд, так что колёса просто скользили, и сдвинуться не получилось.
Хотя некоторые смелые люди сегодня всё ещё ездили:
Но, пожалуй, хорошо, что мне поехать не получилось. Чуть подальше вполне мог застрять.
( Read the rest of this entry » )Оригинал этой записи в личном блоге.
В рабочем офисе на первом этаже сегодня почему-то стало настолько холодно, что все, кто тут были (кроме меня) переселились на третий этаж.
Хотя электрические батареи тут работают на всех этажах, но на втором и третьем почему-то гораздо теплее..
Upd: обещанного в 11-12 часов снега не случилось. Был довольно сильный ветер, видать, он разогнал облака. Сверху их вовсе не осталось, только вдалеке по бокам ещё виднелись. Потому и солнце активно светило, что его облака не закрывали. Но меня оно вовсе не перегревало, как это обычно происходит, потому что на улице было существенно холодно, ведь ещё и ветер..
Upd2: В 3 часа сильный ветер продолжается, а небо стало совершенно белое – полностью прикрыто облаком. Так что теперь, как и прогнозировалось, может случиться и снег, и дождь:
Но с учётом холода и ветра будет это будет неприятно, и нетипично для местной погоды..
Оригинал этой записи в личном блоге.