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

Этот список вопросов был составлен моим прежним начальником – афроадминистратором (в смысле, он был из Южной Африки).
Эти вопросы вполне приемлемы для новых системных администраторов в нашей компании. Хотя их уже давно не принимали, и даже не искали, если только не считать моего нового начальника, который заменил прежнего.
И для меня сейчас эти вопросы оказались полезны, а то я слова забываю, но вот отсюда их вполне вспомнил. Ну и ответы в целом вполне знаю.
Если кому интересно, смотрите все эти вопросы под катом:

( Read the rest of this entry » )

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

Сегодня на работе писал скрипт для копирования файлов rsync’ом с нескольких серверов на бэкапный. И хотя на них всех rsyncd установлен, нормально сконфигурирован, доступ к 873 порту местными файрволами разрешён, но при попытке зайти туда rsync’ом с бэкапного сервера почему-то везде спрашивали пароль..

Погуглил, оказывается, теперь rsync по умолчанию использует ssh (раньше это надо было специально указывать параметром -e ssh), а как теперь напрямую присоединиться к rsyncd – не нашёл.

И только заглянув в аналогичный скрипт, написанный системным администратором из Восточной Африки (Кении), обнаружил, что достаточно после имени хоста написать два двоеточия: rsync -параметры hostname::src /dst/, и тогда он цепляется напрямую к rsyncd.

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

Это не просто шутка, а натурально в Африке обнаружилось:

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

ххх: мне тут в jabber через аськотранспорт вопрос пришел:
> слушай, в чем может быть трабла
> перенес директорию www в tmpfs
> после перезагрузки все сайты на хостинге отдают 404
http://ibash.org.ru/quote.php?id=15557

Znayko: вставьте пропущенное слово: … есть – ума не надо (4 буквы).
despot76: гугл
http://ibash.org.ru/quote.php?id=15559

Сказать, что Java является хорошим ЯП, потому что он работает не зависимо от ОС, это тоже самое, что сказать – анальный секс хорош, потому что он работает не зависимо от пола.
http://ibash.org.ru/quote.php?id=15619

Skywrtr: Сделайте мне отключение клавиатуры, если веб-камера видит кота!
http://ibash.org.ru/quote.php?id=15217

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

узнали о существовании CDN. Какая сука им рассказала?!
Теперь жежешечка вообще не показывается, потому что браузер пытается что-то загрузить из неработающей сети какого-то _корейского_ CDN-провайдера. Ничего поприличнее, конечно же, не нашлось.

$ host l-stat.livejournal.com
l-stat.livejournal.com is an alias for l-stat.livejournal.com.cdngc.net.
l-stat.livejournal.com.cdngc.net has address 175.41.12.69
l-stat.livejournal.com.cdngc.net has address 175.41.12.116

$ host l-userpic.livejournal.com
l-userpic.livejournal.com is an alias for l-userpic.livejournal.com.cdngc.net.
l-userpic.livejournal.com.cdngc.net has address 175.41.12.106
l-userpic.livejournal.com.cdngc.net has address 175.41.12.115

$ tcptraceroute -n 175.41.12.69
Tracing the path to 175.41.12.69 on TCP port 80 (http), 30 hops max
...
 3  109.255.250.254  211.935 ms  8.104 ms  8.000 ms
 4  84.116.238.62  160.239 ms  121.779 ms  138.025 ms
 5  84.116.134.125  151.667 ms  122.748 ms  122.037 ms
 6  84.116.130.33  120.967 ms  127.382 ms  121.810 ms
 7  84.116.130.66  122.759 ms  140.265 ms  141.514 ms
 8  84.116.130.106  123.469 ms  327.008 ms  126.481 ms
 9  * * *
10  * * *
11  * * *
12  * * *
13  * * *
...

$ whois  175.41.12.69
% [whois.apnic.net]
% Whois data copyright terms    http://www.apnic.net/db/dbcopyright.html

% Information related to '175.41.0.0 - 175.41.15.255'

inetnum:        175.41.0.0 - 175.41.15.255
netname:        UTILUS
descr:          UTILUS
descr:          533 5F Lotte BD SEOUL Gasan-dong Geumcheon-gu Seoul
descr:          ***********************************
descr:          Allocated to KRNIC Member.
descr:          If you would like to find assignment
descr:          information in detail please refer to
descr:          the KRNIC Whois Database at:
descr:          http://whois.nic.or.kr/english/index.htm
descr:          ***********************************
country:        KR
admin-c:        SL2321-AP
tech-c:         SL2321-AP
status:         Allocated Portable
remarks:        www.utilus.net
mnt-by:         MNT-KRNIC-AP
mnt-lower:      MNT-KRNIC-AP
changed:        hm-changed@apnic.net 20091214
source:         APNIC

person:         SeungHo Lee
nic-hdl:        SL2321-AP
e-mail:         network@utilus.net
address:        533 5F Lotte BD SEOUL Gasan-dong Geumcheon-gu Seoul, 153-023
phone:          +82-2-3441-0491
fax-no:         +82-2-565-8376
country:        KR
changed:        hostmaster@nida.or.kr 20080102
mnt-by:         MNT-KRNIC-AP
source:         APNIC

% Information related to '175.41.0.0 - 175.41.15.255'

inetnum:        175.41.0.0 - 175.41.15.255
netname:        CDNETWORKS-KR
descr:          CDNetworks
country:        KR
admin-c:        YK603-KR
tech-c:         YK603-KR
status:         ALLOCATED PORTABLE
mnt-by:         MNT-KRNIC-AP
mnt-irt:        IRT-KRNIC-KR
remarks:        This information has been partially mirrored by APNIC from
remarks:        KRNIC. To obtain more specific information, please use the
remarks:        KRNIC whois server at whois.krnic.net.
changed:        hostmaster@nic.or.kr
source:         KRNIC

% This query was served by the APNIC Whois Service version 1.69.1-APNICv1r0 (WHOIS4)

$ whois cdngc.net
...
   Domain Name: CDNGC.NET
   Registrar: TIERRANET INC. D/B/A DOMAINDISCOVER
   Whois Server: whois.domaindiscover.com
   Referral URL: http://www.domaindiscover.com
   Name Server: NS1.PANTHERCDN.COM
   Name Server: NS2.PANTHERCDN.COM
   Status: clientTransferProhibited
   Updated Date: 14-jan-2013
   Creation Date: 19-mar-2009
   Expiration Date: 19-mar-2015

...
Registrant:
   CDNetworks Co., LTD.
   Handong Bldg 67F 8287YeoksamDong GangnamGu
   Seoul, Seoul 135935
   KR

   Domain Name: CDNGC.NET
   Registrar: TIERRANET INC. D/B/A DOMAINDISCOVER

   Administrative Contact, Technical Contact, Zone Contact:
      CDNetworks Co., LTD.
      Cho Byung Ryong
      Handong Bldg 67F 8287YeoksamDong GangnamGu
      Seoul, Seoul 135935
      KR
      82-2-3441-0444
      (822)569-9632 [fax]
      domain@queue.cdnetworks.com

   Domain created on 18-Mar-2009
   Domain expires on 18-Mar-2015
   Last updated on 14-Jan-2013

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

То ли там какой-то хитрый reverse proxy, который фильтрует по странам, то ли оно закэшировалось в нашей корпоративной проксе, но у меня этот сайт до сих пор выглядит вот так:

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

Я чё-то не понял, откуда набралось столько людей, которые на полном серьёзе высказываются в духе “зачем мне бэкап, у меня RAID есть!” ?

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

# tcptraceroute -p 80 www.yandex.ru
traceroute to www.yandex.ru (87.250.251.3), 30 hops max, 40 byte packets
1  www.yandex.ru (87.250.251.3)  0.315 ms  0.306 ms  0.300 ms


# tcptraceroute -p 80 www.google.com
traceroute to www.google.com (173.194.35.178), 30 hops max, 40 byte packets
1  muc03s02-in-f18.1e100.net (173.194.35.178)  0.128 ms  80.033 ms  80.042 ms


# tcptraceroute -p 80 www.microsoft.com
traceroute to www.microsoft.com (64.4.11.42), 30 hops max, 40 byte packets
1  64.4.11.42 (64.4.11.42)  0.504 ms  0.484 ms  0.478 ms


# tcptraceroute -p 80 www.apple.com
traceroute to www.apple.com (92.123.149.15), 30 hops max, 40 byte packets
1  a92-123-149-15.deploy.akamaitechnologies.com (92.123.149.15)  0.384 ms  0.365 ms  0.361 ms

Счастье, конечно, было недолгим. Ни хрена не работает:

# telnet www.yandex.ru 80
Trying 77.88.21.3...
telnet: connect to address 77.88.21.3: Connection refused
Trying 87.250.250.3...
telnet: connect to address 87.250.250.3: Connection refused
Trying 87.250.250.203...
telnet: connect to address 87.250.250.203: Connection refused
Trying 87.250.251.3...
telnet: connect to address 87.250.251.3: Connection refused
Trying 93.158.134.3...
telnet: connect to address 93.158.134.3: Connection refused
Trying 93.158.134.203...
telnet: connect to address 93.158.134.203: Connection refused
Trying 213.180.204.3...
telnet: connect to address 213.180.204.3: Connection refused
Trying 213.180.193.3...
telnet: connect to address 213.180.193.3: Connection refused

# telnet www.google.com 80
Trying 173.194.35.180...
telnet: connect to address 173.194.35.180: Connection refused
Trying 173.194.35.176...
telnet: connect to address 173.194.35.176: Connection refused
Trying 173.194.35.177...
telnet: connect to address 173.194.35.177: Connection refused
Trying 173.194.35.178...
telnet: connect to address 173.194.35.178: Connection refused
Trying 173.194.35.179...
telnet: connect to address 173.194.35.179: Connection refused
Trying 2a00:1450:4016:801::1010...
telnet: connect to address 2a00:1450:4016:801::1010: Network is unreachable

Спасибо криворуким уродам из отдела server engineering за мою пошатнувшуюся психику.

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

её сегодня сделали недоступной. Туда ей и дорога. Учитывая TTL в двое суток, оно ещё пару дней работать не будет.

$ dig facebook.com -t NS @b.gtld-servers.net.

; <<>> DiG 9.7.0-P1 <<>> facebook.com -t NS @b.gtld-servers.net.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30540
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 5, ADDITIONAL: 5
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;facebook.com.            IN    NS

;; AUTHORITY SECTION:
facebook.com.        172800    IN    NS    ns1.facebook.com.
facebook.com.        172800    IN    NS    ns2.facebook.com.
facebook.com.        172800    IN    NS    ns3.facebook.com.
facebook.com.        172800    IN    NS    ns4.facebook.com.
facebook.com.        172800    IN    NS    ns5.facebook.com.

;; ADDITIONAL SECTION:
ns1.facebook.com.    172800    IN    A    204.74.66.132
ns2.facebook.com.    172800    IN    A    204.74.67.132
ns3.facebook.com.    172800    IN    A    66.220.151.20
ns4.facebook.com.    172800    IN    A    69.171.245.32
ns5.facebook.com.    172800    IN    A    66.220.145.65

;; Query time: 10 msec
;; SERVER: 192.33.14.30#53(192.33.14.30)
;; WHEN: Wed Mar  7 07:53:17 2012
;; MSG SIZE  rcvd: 200

$ dig www.facebook.com @204.74.66.132

; <<>> DiG 9.7.0-P1 <<>> www.facebook.com @204.74.66.132
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 62780
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2
;; WARNING: recursion requested but not available

;; QUESTION SECTION:
;www.facebook.com.        IN    A

;; AUTHORITY SECTION:
www.facebook.com.    86400    IN    NS    glb2.facebook.com.
www.facebook.com.    86400    IN    NS    glb1.facebook.com.

;; ADDITIONAL SECTION:
glb2.facebook.com.    3600    IN    A    69.171.255.10
glb1.facebook.com.    3600    IN    A    69.171.239.10

;; Query time: 110 msec
;; SERVER: 204.74.66.132#53(204.74.66.132)
;; WHEN: Wed Mar  7 07:53:32 2012
;; MSG SIZE  rcvd: 104

И то же самое отвечают все остальные бывшие авторитетные серверы:

( Read the rest of this entry » )

Оригинал этой записи в личном блоге.
Любые материалы из этого блога запрещается использовать на сайте livejournal.ru в любой форме и любом объёме.

При обследовании одного сервера на предмет используемой версии OpenSSL обнаружилось, что… никакой:

# ldd apache/modules/mod_ssl.so |grep libssl
	libssl.so.1.0.0 => not found

Апач был собран афроадминистраторами из исходников. Но при сборке маршрут к библиотеке явно не указали, и в ld.so.conf тоже не написали, вот она и не находится. Тем не менее, апач таки успешно запускается, и SSL в нём каким-то чудом работает.

Дальнейшее препрарирование показало ещё более прекрасное:

# ldd apache/modules/libphp5.so |grep libssl
	libssl.so.1.0.0 => /opt/openssl/lib/libssl.so.1.0.0 (0x00002ad00e36d000)
	libssl.so.6 => /lib64/libssl.so.6 (0x00002ad0101b3000)

PHP, понятное дело, тоже был собран афроадминистраторами из исходников.

А теперь вопросы:
Вопрос 1, достаточно простой: КАК они умудрились собрать PHP с двумя разными версиями одной библиотеки одновременно?
Вопрос 2, посложнее: а нафига они это сделали?
Вопрос 3: а всё-таки как апач находит библиотеку при загрузке mod_ssl? Никаких LD_PRELOAD и LD_LIBRARY_PATH в запускающем скрипте апача нет, я проверял и в самом скрипте, и в environment’е запущенного апача.
Вопрос 4: и что надо с такими администраторами после всего этого сделать?

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