файл отрицательного размера

На работе меня попросили установить свежую версию 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

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

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

опять встретил загадочные грабельки..

С большинства серверов всё нормально копировалось, а с трёх почему-то
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 должен видеть всё, ан нет:

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

В одном регионе есть некий серверочек. Нужно поднять аналогичный в другом регионе и связать с первым. Казалось бы, задачка элементарная.
Создал машинку для второго (виртуальную, хотя это не принципиально), поставил туда CentOS 7, как на первой, весь нужный софт, всё сконфигурировал, запустил, вроде работает.
Стал проверять, можно ли к нему прицепиться с первого сервера — а, блин… telnet: connect to address x.x.x.x: No route to host.
ip route get x.x.x.x показывает маршрут через default gateway, вполне логично.
Попробовал с обратной стороны — со второго к первому — успешно соединяется. Попингал обе машинки друг с друга — с обеих сторон работает. Значит, маршрутизация точно в обе стороны правильная, а чего ж маршрут-то не находится??

Видать, где-то по дороге не пускают. Проверил файрволы в обоих регионах, никаких запретов в сторону новой машинки, да и всей тамошней подсетки, вовсе нету. Да и сам-то я на неё по ssh сразу зашёл без всяких дополнительных правил, значит точно никаких запретов нету. На всякий случай добавил явное правило, чтоб туда пускали на нужный порт этого сервера, а ничего не поменялось, всё такое же No route to host.

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

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

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

Ставил CentOS 6.6 (в vmware’ной виртуалке, но это не существенно). Сделал 3 раздела (boot, swap, всё остальное в / ). И тут, внезапно, получил пинок:

Спасибо, что хоть предупредили, только поздновато..

Удивился, вернулся обратно к разметке диска, но никаких опций чтоб выбрать MBR вместо GPT, не нашёл. Хотя там диск всего-то на 2 терабайта, MBR вполне прокатил бы, но похоже, этот CentOS больше любит GPT, только заранее про это не предупредил.

Доставил систему, и она, как и обещали, не загрузилась. Поменял в настройках BIOS на EFI, благо в vmware это одним кликом делается, но никакого эффекта. Но это-то понятно, EFI без явных настроек в своём разделе ничего грузить не будет.

Пришлось ставить всё заново под EFI. Инсталлятор ругнулся, что не видит EFIного раздела, предложил создать /boot/efi. Ну создал, всё поставилось без ошибок, успешно загрузилось, но.. внезапно сеть не работает. Сначала я подумал, что выбрал неподдерживаемый сетевой адаптер, но для проверки запустил ifup eth0, и сеть появилась. Перезагрузил — опять нету..

Пошёл копать, и нашёл, что в /etc/sysconfig/network-scripts/ifcfg-eth0 почему-то ONBOOT=no. Поменял на yes, заработало, как положено. Но с какого бодуна там этот no взялся на единственном сетевом интерфейсе, так и не понял..

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

Перенесли тут как-то перловый скриптик на другую  машину. А он возьми да и сломайся. И пошёл я смотреть, отчего это. Ругался он при попытке распарсить XML-файл (да-да, тем самым XML::XPath->new(), про который был предыдущий пост) но ругался довольно странно:

error in processing external entity reference at line 2, column 58, byte 80:
<?xml version="1.0"?>
<!DOCTYPE DataAlertService SYSTEM "DataAlertService.dtd">
=======================================================^

Потратив всего каких-то полдня, я понял, что ругается он вовсе не на указанное место, и даже не на сам этот XML. А на DTD. Потратив ещё полдня, я понял, что на этой машине XML-парсер тупо не понимает parameter entities в DTD.
Это макросы типа <!ENTITY % id 'id CDATA #REQUIRED'>, которые потом можно в том же DTD использовать: <!ATTLIST Official %id; ...

Вот на прежней древней солярке понимал, на моей десктопной убунте понимает, а на этой грёбанной CentOS (5.5, последний релиз, все дела) – не понимает. И после этого мне ещё будут рассказывать о прелестях этих ваших редхатов..

Оригинал этой записи. Комментировать можно тут или там.