written for http://forum.firstvds.ru/viewtopic.php?f=3&t=8233

Перезагрузился, и теперь опять абсолютно даже на IPv4 firewall не работает, как в начале января. Теперь опять показывает все нули по `ipfw show` (вообще ни одно правило не ловит даже IPv4 пакеты), динамические правила по `ipfw -d show` до сих пор отсутствуют — я вообще до сих пор ни разу не видел динамических правил на вашей ISPFreeBSD8. (На ISPFreeBSD6 — без проблем.)

Когда будет исправлено? Почему до сих пор нет ответа? Это затрагивает только пользователей, у которых IPv6, или у всех на ISPFreeBSD8 не работает от перезагрузки к перезагрузке? Почему до сих пор нет никакого официального заявляния, что ваша поддержка IPv6 нифига не работает и делает ipfw непригодным даже для IPv4?

З.Ы. swg, к правилам нечего придираться — попробуйте сами правила писать, когда ни одно из них никакого эффекта не оказывает. Я их писал именно в начале января, когда они вообще никакого эффекта не оказывали. Они кое-как глючно работали исключительно после второй перезагрузки вторым специалистом седьмого числа.

P.P.S. Только что заметил, что вообще моё сообщение о неработоспособности ipfw с IPv6 удалили из новостей! Вот это прогресс! Хотелось бы объяснений!

====

К новости об IPv6 неработоспособность ipfw при IPv6, между прочим, имеет самое что ни на есть прямое отношение. Моё удалённое сообщение в той теме было кратко и по делу, и конкретно про IPv6. Кто не верит, можете сами убедиться: я перепостил, но тема теперь закрыта, причём ещё с возражениями о том, что за “сообщения не по теме” вообще банят.

А мне нечего добавить в поддержку через my.firstvds.ru. Вся проблема (и про v4, и про v6) была описана мной в начале января, осмотрена и протестирована двумя вашими специалистами, которые совершили две перезагрузки моего VDS. Было сообщено, что исправление будет, но вопрос был закрыт.

Это не моя задача открывать закрытые вопросы, когда вам уже должно быть совершенно ясно, что ipfw у вас полностью сломан. Если бы вы являлись порядочной конторой, то уже давным давно следовало бы сообщить, что ваша поддержка IPv6 делает невозможным использование ipfw даже для IPv4. Но это же трудно, после анонса IPv6, признать, что работает всё очень криво. Вот вы и прибегаете к удалению сообщений, вместо признания существующих проблем, которые затрагивают каждого пользователя ISPFreeBSD8 IPv6.

Это проблема не уникальна к моему VDS, поэтому нет смысла решать её исключительно в закрытом порядке. Другим пользователям, небось, тоже интересно.

written for forum.firstvds.ru: http://forum.firstvds.ru/viewtopic.php?f=14&t=8247&p=41815#p41815

Ваши изменения шаблонов привели к неработоспособности apache при стандартных apache22 + nginx из ispmgr (nginx установлен через ispmgr в начале января).

Я apache2 не пользуюсь, но как советуете теперь обращаться к ispmgr?

(Хочу перезагрузить весь сервер, а `shutdown -r +1` не работает. Что следует использовать, кроме ispmgr?)

[code]
# /usr/local/etc/rc.d/apache22 start
Performing sanity check on apache22 configuration:
httpd: Syntax error on line 474 of /usr/local/etc/apache22/httpd.conf: Syntax error on line 1 of /usr/local/etc/apache22/Includes/rpaf.conf: Cannot load /usr/local/libexec/apache22/mod_rpaf.so into server: Cannot open “/usr/local/libexec/apache22/mod_rpaf.so”
Starting apache22.
httpd: Syntax error on line 474 of /usr/local/etc/apache22/httpd.conf: Syntax error on line 1 of /usr/local/etc/apache22/Includes/rpaf.conf: Cannot load /usr/local/libexec/apache22/mod_rpaf.so into server: Cannot open “/usr/local/libexec/apache22/mod_rpaf.so”
/usr/local/etc/rc.d/apache22: WARNING: failed to start apache22
# ll /usr/local/etc/apache22/
total 132
drwxr-xr-x 2 root wheel 512 Jan 7 02:52 Includes
drwxr-xr-x 2 root wheel 512 Jan 7 01:16 envvars.d
drwxr-xr-x 2 root wheel 512 Jan 7 01:16 extra
-rw-r——- 1 root wheel 17239 Jan 3 17:54 httpd.conf
-rw-r——- 1 root wheel 17239 Jan 3 17:06 httpd.conf.2012-01-03T173341-0800.orig
-rw-r——- 1 root wheel 17240 Jan 3 17:54 httpd.conf~
-rw-r—r— 2 root wheel 12958 Sep 22 02:43 magic
-rw-r—r— 2 root wheel 49815 Sep 22 02:43 mime.types
-rw-r—r— 1 root wheel 1164 Dec 30 17:12 server.crt
-rw-r—r— 1 root wheel 887 Dec 30 17:12 server.key
drwxr-xr-x 2 root wheel 512 Jan 7 01:16 ssl.crt
drwx——— 2 root wheel 512 Jan 7 01:16 ssl.key
# ll /usr/local/etc/apache22/Includes/
total 10
-rw-r—r— 2 root wheel 318 Dec 24 2009 awstats.conf
-r—r—r— 2 root wheel 89 Sep 22 02:43 no-accf.conf
-rw-r—r— 2 root wheel 510 Dec 24 2009 phpmyadmin.conf
-rw-r—r— 1 root wheel 106 Jan 3 17:05 rpaf.conf
-rw-r—r— 2 root wheel 352 Oct 7 2010 secure.conf
# ll /usr/local/libexec/apache22/mod_r*
-rwxr-xr-x 2 root wheel 39646 Sep 22 02:43 /usr/local/libexec/apache22/mod_reqtimeout.so
-rwxr-xr-x 2 root wheel 164275 Sep 22 02:43 /usr/local/libexec/apache22/mod_rewrite.so
-rwxr-xr-x 2 root wheel 28584 Jan 25 21:40 /usr/local/libexec/apache22/mod_rpaf2.so
#
[/code]

Собственно, в добавку: почему вообще у вас вот так напросто отсутствует контроль качества?

Очевидно, проблема в том, что ispmgr создаёт rpaf.conf вне шаблона, хотя бывший mod_rpaf.so линковался из шаблона. Так это же значит, что вы все apache22 сломали, у кого nginx был установлен стандартными средствами из ispmgr!

After many years in the BSD land, late December 2011 I’ve started using the 2011 release of Debian Linux on Linode512 upgraded to Linode768 (plan to “upgrade” back to 512 after a while on 768).

My list of bugs/annoyances is as follows (I might update this entry later on, too):

* installing ntpd package corrects your date without any trace whatsoever what the correction was; I guesstimate that it’s a package bug, where they run ntpdate or something, but maybe ntpd itself is to blame

* logs are not rotated at midnight. stupid linux runs logrotate as part of the /etc/cron.daily/ at 6:25 on my box (seriously, how entirely dumb is that?) The best fix would probably be `echo “0 0 * * * root /etc/cron.daily/logrotate” »/etc/cron.d/logrotate`, but I’m entirely amazed that anyone finds it acceptable to do daily/weekly/monthly rotation of logs at random times of the day, other than 00:00:00 (renaming a few files doesn’t take that many resources; if you really care about overconsumption at 00:00:00, why not ensure that logs are never compressed during the 00:00:00 run?)

* there is no `jot`. seriously, no jot? `apt-get install athena-jot`

* iptables has no way of storing any rules permanently. Have to install `iptables-persistent` with apt. However, iptables-persistent only works with IPv4, for IPv6 you have to do some hacking. The whole thing where IPv6 is controlled by `ip6tables`, and never by `iptables`, arguably adds to show just how little Linux cares about IPv6 adoption.

I started using Bitbucket for my private repositories a very short while ago, since they now support git.

Unlike github.com and gitorious.org, Bitbucket provides unlimited private repository support for both git and hg, and they also have Australian roots, for a bit of redundancy in who to trust your repositories to. :-)

The best thing about git is that due to the strong sha1 hashes and the distributed nature of each individual repository, you don’t have to worry about anyone else messing up with your repository without you ever noticing during the course of normal operations, since that’s merely impossible or at the very least very-very-very improbable for the near future. So, pretty much, any git hosting will do for a public repo, and if they misbehave, it’ll be entirely obvious very quickly and you can drop them with little to no ill effects whatsoever. This is why Linus Torvalds said in his Google tech talk, let me paraphrase / rephrase / extrapolate, that he’d trust an anonymous hoster from Nigeria with a git repo, but wouldn’t ever trust Google Code with an svn one.

However, in case of private repositories, you obviously do care for the private nature of your bits. Which poses a good question: can you actually trust any shared external source service to have even read access for your private repositories? How much care have they taken to safeguard your private repositories, and make sure no unauthorised people ever get access to it?

One thing for sure, is that I would never trust an outside party to have access to my /etc/master.passwd or /etc/shadow (somehow etckeeper on the 2011 Debian does keep track of your shadow file!). For other things, it’s still debatable who to trust, but I can only hope that Bitbucket has taken all the measures at ensuring my private stuff stays private…

I don’t have stuff worth a million dollars in my private repositories (or, at least, I’m not yet aware of such specific and immediate potential), but I still may have stuff there that one might easily classify as trade secrets (and rightly so), hence an unintentional release would make me very uncomfortable to say the least.

With OpenBSD 5.0 under KVM on ARPNetworks, all you have to do is “disable mpbios”, and it all seems to work. However, not without subtle problems.

First, I’ve noticed that if you have lots of disk activity, plus lots of output through ssh, then you get periodic networking stalls very easily, with “em0: watchdog timeout — resetting” appearing repeatedly (although, to be fair, the stall only lasts a couple of seconds, and your sessions resume without any noticeable ill effects).

For example, you can find the following in /var/log/messages after checking out all the 3 BSD systems from local CVS trees, locally:

Jan 21 19:51:39 grok /bsd: em0: watchdog timeout -- resetting
Jan 21 19:52:16 grok last message repeated 2 times
Jan 21 19:53:09 grok /bsd: em0: watchdog timeout -- resetting
Jan 21 19:58:32 grok /bsd: em0: watchdog timeout -- resetting

Then, now I’m running Java with {OpenGrok, indexing 3 source trees, and the run queue seems to be merely about 4, as you can see from the load average below. The regular non-mp /bsd. So, guess what, something is broken yet again, and `top` shows all zeros for all the CPU states, and `systat vmstat 1` doesn’t work, either, returning “> The alternate system clock has died!” after a couple of seconds, without updating any info at all whatsoever.

This is what `top -U opengrok -s1` shows, notice the 0.00% for all CPU times, as well as for the process 30390 itself. It shows “98.4% idle” on first iteration, but then goes back to 0.0% as below. (However, wallclock works just fine, without any abnormalities, and the system otherwise appears to run just fine, too.)

load averages:  3.80,  3.78,  3.92
36 processes:  1 running, 33 idle, 1 stopped, 1 on processor
CPU states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle
Memory: Real: 346M/581M act/tot Free: 402M Cache: 187M Swap: 32M/1012M

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
30390 opengrok  59    0  543M  297M run       -       207:20  0.00% java
24752 opengrok  -6    0  924K 1668K sleep     piperd    0:15  0.00% ectags
32716 opengrok  -6    0  656K 1528K idle      piperd    0:10  0.00% ectags
11857 opengrok  -6    0  840K 1580K sleep     piperd    0:10  0.00% ectags
 2934 opengrok  18    0 1340K 2092K idle      pause     0:01  0.00% tcsh

So, doesn’t really look like this would be providing a reliable and dependable server solution without some extra hacking…

This is a nice question which I recall being asked in one of my interviews a few years back.

I recall I answered it with a `sockstat` (FreeBSD), but the interviewer expected more on the lines of `lsof` (Linux and other *NIX). The pages below provide an excellent overview of just how flexible (yet divergent) UNIX systems are, and how a little shell scripting can get you a long way.

http://troysunix.blogspot.com/2011/03/finding-open-files-in-freebsd.html
http://troysunix.blogspot.com/2011/03/finding-open-files-in-linux.html
http://troysunix.blogspot.com/2011/03/finding-open-files-in-solaris.html

In addition, a short cheat-sheet summary would be:

* fstat(1) on 4.3BSD-derived systems (FreeBSD, OpenBSD, NetBSD, but not OS X);

* fuser(1) with some shell scripting on some POSIX systems (Linux, OpenBSD, OS X, FreeBSD since 9.0);

* lsof(1) on Linux, FreeBSD ports, OS X;

* sockstat(1) on FreeBSD, especially if you want just the listening sockets;

* proc(5) on Linux.

The fuser(1), being POSIX, seems especially entertaining: it outputs the PIDs onto stdout, yet the hints of which kinds of files are open onto stderr, which makes it possible to redirect the stderr output to /dev/null, whereas use the stdout output in further processing as command-line arguments to ps(1) and such, without any need for any more advanced inline editing. Really cool stuff. :-)

In turn, if you just need the listening and open sockets:

`lsof | fgrep -e TCP -e UDP` (is there a better way?) on Linux or OS X;

`sockstat` on FreeBSD;

`fstat | fgrep internet` on OpenBSD.

written for forum.firstvds.ru: http://forum.firstvds.ru/viewtopic.php?f=3&t=8233

В интересах продолжения темы IPv6 до сих пор не работает из форума Новости, хотелось бы разъяснений, почему ipfw всё же даже на IPv4 не работает. Далее приведу наглядный пример с сервера без каких-либо изменений с перезагрузки. Прошу заметить, что правило 02200, которое замечательно работает на вашей ISP FreeBSD6 и ловит все пакеты на порту ssh, на данной ISP FreeBSD8 до сих пор не поймало ни одного пакета вообще. По неизвестным причинам, весь мой ssh трафик с домашней сети ловится правилом 44300, которое ну исключительно только под порт 443 предназначено.

Хочется заметить, что даже если бы я использовал порт 443 вместо 22 для ssh, то всё равно не может данное 02200 правило быть незадействованным в течение целой недели. Но на порте 443 у меня крутится обычный Apache, а не OpenSSH. Пока что использую IPv4 для ssh, настройки по умолчанию.

Пожалуйста, разъясните — я совершенно перепутал синтаксис ipfw, или он у вас действительно очень и очень серьёзно глючит до неузнаваемости? Почему вы до сих пор не сделали каких-либо Security Advisory про неработоспособность? Пользователи должны быть сами в курсе, что ipfw у вас не работает? Уже более двух недель прошло с момента моего оригинального запроса по поводу неработоспособности ipfw, никаких ETA до сих пор не получал.

# ipfw show ; uptime ; uname -mrsv ; date
00100  74098 23241496 allow ip from any to any via lo0
00200      0        0 deny ip from any to 127.0.0.0/8
00300      0        0 deny ip from 127.0.0.0/8 to any
00400      0        0 deny ip from any to ::1
00500      0        0 deny ip from ::1 to any
00600      0        0 allow ipv6-icmp from :: to ff02::/16
00700      0        0 allow ipv6-icmp from fe80::/10 to fe80::/10
00800      0        0 allow ipv6-icmp from fe80::/10 to ff02::/16
00900      0        0 allow ipv6-icmp from any to any ip6 icmp6types 1
01000      0        0 allow ipv6-icmp from any to any ip6 icmp6types 2,135,136
02200      0        0 allow tcp from any to me dst-port 22 in setup limit src-addr 12
05300    644    43646 allow tcp from any to me dst-port 53 in setup limit src-addr 7
08080     26     1384 deny tcp from any to me dst-port 808
08099   2716  1448701 allow tcp from any to me dst-port 80 in setup limit src-addr 16
44300 419807 59061309 allow tcp from { 76.220.XX.XX or 99.124.XXX.XXX/27 } to me dst-port 443 in setup limit src-addr 16
44310      8      412 deny tcp from any to me dst-port 443 in setup limit src-addr 4
65535 153984 73335150 allow ip from any to any
11:57AM  up 6 days,  7:53, 5 users, load averages: 0.01, 0.05, 0.04
FreeBSD 8.2-STABLE FreeBSD 8.2-STABLE #0 r112:113: Mon Dec 19 08:17:00 IRKT 2011     root@freebsd8-amd64.ispsystem.net:/root/src/sys/amd64/compile/ISPSYSTEM  amd64
Fri Jan 20 11:57:06 PST 2012

Apparently, installing ntp in Debian results in your clock being corrected, with no proof whatsoever that the correction took place, and the amount of any such correction. An obvious security flaw, if you ask me. On the other hand, in the Linux land, that’s probably just another day.

Заказал тридцатого декабря местного времени FreeBSD8 сервер с IPv6 под новогоднюю скидку. С самого начала, IPv6 адрес вообще не работал — очевидно, у сервера забыли настроить gateway. Починили в течение суток после обращения в поддержку.

Потом оказалось, что firewall (ipfw) вообще тоже не работает. На IPv4 просто-напросто не влияет на пакеты, а на IPv6 — даже не выключается и не включается (нет прав на изменение `sysctl net.inet6.ip6.fw.enable`). Перезагрузка сервера (2012-01-03/04) не помогла, после перезагрузки всё так же сплошные нули по `ipfw show`, и выдаётся ошибка при добавлении правила 65535. В течение недели после запроса каким-то образом молча вроде стал работать IPv4 числа эдак седьмого (причём работает очень подозрительно: элементарное правило, которое ловило ssh пакеты во FreeBSD6, на новом FreeBSD8 пакеты не ловит, пропуская пакеты к более высоким правилам), а про IPv6 до сих пор вообще ничего. При этом сам запрос числится закрытым (нет иконки про то, что над ним кто-то всё ещё работает), последнее сообщение датировано седьмым числом, «В течение ближайшего времени проблема будет устранена. Приносим извинения за неудобства.», проблема до сих пор присутствует десять дней после последнего сообщения, ETA отсутствует.

Так что, резюмируя, даже сами IPv6 адреса не работают — никто интернетом без firewall’а в наши времена не пользуется. :-( Дополнительно, даже ipfw на IPv4 глючит. В прибавку, за все эти проблемы ещё нужно целый рубль каждый месяц выкладывать! Грабёж среди бела дня! ;-)

Подробнее: http://forum.firstvds.ru/viewtopic.php?f=15&t=8060&start=30#p41737

What can I say? HGST provides an excellent example of how you should NOT be running your web-site.

% http_ping -count 4 -interval 1 "http://www.hitachigst.com/internal-drives/deskstar/deskstar-7k1000d"; date
29131 bytes from http://www.hitachigst.com/internal-drives/deskstar/deskstar-7k1000d: 3544.97 ms (7.376c/3485.42r/52.173d)
29131 bytes from http://www.hitachigst.com/internal-drives/deskstar/deskstar-7k1000d: 3694.24 ms (8.122c/3612.4r/73.713d)
29131 bytes from http://www.hitachigst.com/internal-drives/deskstar/deskstar-7k1000d: 3228.26 ms (7.236c/3160.14r/60.882d)
29131 bytes from http://www.hitachigst.com/internal-drives/deskstar/deskstar-7k1000d: 3626.39 ms (19.465c/3558r/48.926d)

--- http://www.hitachigst.com/internal-drives/deskstar/deskstar-7k1000d http_ping statistics ---
4 fetches started, 4 completed (100%), 0 failures (0%), 0 timeouts (0%)
total    min/avg/max = 3228.26/3523.46/3694.24 ms
connect  min/avg/max = 7.236/10.5497/19.465 ms
response min/avg/max = 3160.14/3453.99/3612.4 ms
data     min/avg/max = 48.926/58.9235/73.713 ms
Sun 15 Jan 2012 19:05:01 PST

3.5s to generate a static 29k web-page? Repeatedly, three and a half seconds? Are they nuts or what? You can certainly notice the slowness as you try to navigate the actual site, so this is not some kind of test artefact.

No, seriously, how can you slow do a static web-site like that? Someone, please explain? The site doesn’t even have any kind of shop or anything. Entirely static!