http://uptime.netcraft.com/up/graph?site=www.firstvds.ru

Какой позор! Перешли на CloudFlare, вот смеху-то! Хостер, называется!

Собственно, совершенно не удивительно: как оказалось, на их глючной ISPFreeBSD8 нет поддержки динамических правил ipfw, т.е. “keep-state” и “limit” работать не будут! И от “setup” тоже толку нет! Из-за этих мудаков я в январе потратил несколько часов на написания правил ipfw для нового сервера на ISPFreeBSD8, которые абсолютно на их сломанной виртуализации не работают! Без динамических (keep-state) правил, полностью все правила нужно переписывать с нуля, с абсолютно другой ментальностью! А потом ещё окажется, что их говёная исковерканная фря ещё чего-нибудь не поддерживает!

В добавок, их NS-сервера постоянно глючат. Несколько раз проверял ns2.firstvds.ru, `dig @ns2.firstvds.ru`, как мои домены, так и сам firstvds.ru. Постоянно записи на половину доменов отсутствует! Только ns1.firstvds.ru выдаёт записи! Честное слово, что за дерьмовым провайдером я пользуюсь уже который год?

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, поэтому нет смысла решать её исключительно в закрытом порядке. Другим пользователям, небось, тоже интересно.

====

Мне кажется, что вы всё-же продаёте полный набор услуг, а не просто сами адреса и трафик, так что неработоспособность одной из главных функций вашей виртуализации ISPFreeBSD8 является довольно серьёзной проблемой.

Я не знаю, какие правила создаёт ipsmgr, но мне всё-таки так кажется, что если даже ни одно из правил ipfw не может поймать ни одного пакета (все нули по `ipfw show`, даже “65535 0 0 allow ip from any to any”), то ваши ipsmgr правила тоже вряд-ли будут работать. (Разумеется, net.inet.ip.fw.enable включён, =1.)

И в конце концов, как ни крути, но ISPserver это всё-таки тоже ваша контора. В крайнем случае — вы их самый прямой клиент.

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

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!

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

Заказал тридцатого декабря местного времени 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

This is seriously the highest level of incompetence for a hosting company that claims to be the number one in the Russian market for virtual dedicated servers. The company is actually owned (or otherwise has roots) to ISPsystem, the people who make the FreeBSD VDS thing, together with a number of (rather horrible, must I say) control panels (the FreeBSD virtualisation itself that they offer seems nice, although given the other parts, I’d not be surprised if it’s equally horrible deep within, too).

Below is a session from a brand new VDS server from firstvds.ru, created 2011-12-31. Notice that they’ve been offering IPv6 addresses since a few months ago, since 2011-10-14.

cvs# time traceroute www.netbsd.org
traceroute to www.netbsd.org (204.152.190.12), 64 hops max, 52 byte packets
 1  gw.webdc.ru (188.120.247.254)  3.283 ms  0.479 ms  0.446 ms
 2  92.63.108.89 (92.63.108.89)  0.329 ms  0.797 ms  0.581 ms
 3  xe012-438.RT.MR.MSK.RU.retn.net (87.245.254.61)  1.375 ms  3.878 ms  1.553 ms
 4  xe000-8.RT.TLX.NYC.US.retn.net (87.245.233.114)  124.487 ms  124.173 ms  123.801 ms
 5  nyiix.r1.lga1.isc.org (198.32.160.95)  124.964 ms  125.565 ms  126.134 ms
 6  int-0-5-0-0.r1.pao1.isc.org (149.20.65.137)  199.516 ms  199.786 ms  199.262 ms
 7  int-0-0-1-0.r1.sql1.isc.org (149.20.65.10)  202.798 ms  202.221 ms  203.148 ms
 8  www.netbsd.org (204.152.190.12)  196.944 ms  199.323 ms  196.995 ms
0.006u 0.009s 1:01.06 0.0%	0+0k 0+0io 0pf+0w
cvs# time traceroute6 www.netbsd.org
connect: No route to host
0.000u 0.020s 0:05.29 0.3%	24+136k 0+0io 1pf+0w
cvs# time host www.netbsd.org
;; reply from unexpected source: 188.120.242.64#53, expected 127.0.0.1#53
www.netbsd.org has address 204.152.190.12
;; reply from unexpected source: 188.120.242.64#53, expected 127.0.0.1#53
www.netbsd.org has IPv6 address 2001:4f8:3:7:2e0:81ff:fe52:9a6b
;; reply from unexpected source: 188.120.242.64#53, expected 127.0.0.1#53
www.netbsd.org mail is handled by 10 mail.netbsd.org.
0.007u 0.061s 0:03.52 1.7%	1935+475k 0+0io 14pf+0w
cvs# cat /etc/resolv.conf 
nameserver      127.0.0.1
nameserver      188.120.247.2
nameserver      188.120.247.8
nameserver      82.146.59.250
cvs# dig cvs.su
;; reply from unexpected source: 188.120.242.64#53, expected 127.0.0.1#53

; <<>> DiG 9.6.-ESV-R5 <<>> cvs.su
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 27038
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cvs.su.				IN	A

;; ANSWER SECTION:
cvs.su.			2560	IN	A	188.120.242.64

;; Query time: 10 msec
;; SERVER: 188.120.247.2#53(188.120.247.2)
;; WHEN: Sat Dec 31 08:03:37 2011
;; MSG SIZE  rcvd: 40

cvs# time dig cvs.su
;; reply from unexpected source: 188.120.242.64#53, expected 127.0.0.1#53

; <<>> DiG 9.6.-ESV-R5 <<>> cvs.su
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 40280
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;cvs.su.				IN	A

;; ANSWER SECTION:
cvs.su.			2560	IN	A	188.120.242.64

;; Query time: 4 msec
;; SERVER: 188.120.247.2#53(188.120.247.2)
;; WHEN: Sat Dec 31 08:03:51 2011
;; MSG SIZE  rcvd: 40

0.000u 0.006s 0:01.00 0.0%	0+0k 0+0io 0pf+0w
cvs# ifconfig 
igb0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=1bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4>
	ether 00:1e:67:05:9b:5e
	inet 188.120.242.64 netmask 0xffffffff broadcast 188.120.242.64
	inet6 2a01:230:2::10d prefixlen 64 
	nd6 options=3<PERFORMNUD,ACCEPT_RTADV>
	media: Ethernet autoselect (100baseTX <full-duplex>)
	status: active
igb1: flags=8802<BROADCAST,SIMPLEX,MULTICAST> metric 0 mtu 1500
	options=1bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4>
	ether 00:1e:67:05:9b:5f
	media: Ethernet autoselect
	status: no carrier
ipfw0: flags=8801<UP,SIMPLEX,MULTICAST> metric 0 mtu 65536
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
	options=3<RXCSUM,TXCSUM>
cvs# uname -a
FreeBSD cvs.su 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
cvs# netstat -rn
netstat: kvm not available: /dev/mem: No such file or directory
Routing tables
rt_tables: symbol not in namelist
cvs# 

Note that it’s supposed to come with IPv6, for which they do actually charge you 1 RUR monthly fees, but the extra IPv6 (was part of the order) doesn’t actually work at all.

This is in addition to them not actually providing any IPv6 name servers, neither local nor authoritative (the .su and .ru do actually already support IPv6).

In addition, notice the fuck up with the nameservers that they specify: they specify 127.0.0.1, whereas either due to their virtualisation or whatever else, the named doesn’t actually reply from 127.0.0.1, so, nothing that makes any use of any names actually works smoothly, due to obvious security concerns within the resolver software. In turn, this amounts to a delay of at least one second for every name query. The sshd logins, the traceroute, anything, extra multiple-second delays. The whole thing is honestly far below any possible incompetence.

The final remark I have to say in my mother tongue.

Честное слово, ну не дебилы?