The best thing that you could be doing with market dominance is making a change for the better.
What did Apple do with its market dominance? It killed the CPU-hungry and battery-unfriendly Adobe Flash technology, and adopted open standards that any other manufacturer can implement, too, for increased interoperability and convenience of everyone involved (other than Adobe, of course, as well as the people who were too lazy or incompetent to use HTML5 instead of Adobe Flash for making their web-sites).
What did Google do with their market dominance? Through Google Mail and Google Voice, it brought affordable email and telephone solutions to the market, eliminated the need to pay huge fees for text messaging, as well as the ability to have mnemonic telephone numbers for mere mortals.
But what about the rest of the industry? How come most public entities entirely disregard the need to use their market dominance for the greater good?
Say, LowEndBox.com, is arguably the dominant place to get offers on highly competitive VPS hosting. Yet, IMHO, they are currently failing to use their market dominance to improve the market place. Why are there still providers around that offer hosting services without providing any test IPs (let alone download files)? Or even precise locations of their data-centres? Or virtualisation technologies (“Xen PV” is entirely different from “Xen HVM”; WTF is “Xen”?). Or whether or not they support IPv6.
The IPv6 is an interesting topic, IMHO. This year, on 2012-06-06, is the http://www.WorldIPv6Launch.org/ . Even the behemoth US telecoms like AT&T and ubiquitous CDNs like Akamai and Limelight, together with Google and Facebook, have agreed to permanently enable IPv6 for its subscribers, for good. Yet many hosting providers are still keeping quiet about their IPv6 support. (Many actually do support it, so the sole quietness on the subject is not an indication that support is surely lacking). IMHO, sites like LowEndBox.com have a moral obligation to the internet society at large, to use its powers to promote stuff like IPv6 (which is now finally so close to actually being useful within a couple of months) and other transparency. It’s entirely easy to make a simple rule of clearly stating whether IPv6 is supported or not, in every post, making it clear who is who in the business, and giving the clear incentive to the providers in supporting IPv6.
I had a funny dream last night (Saturday to Sunday, 2012-02-04/05 PT). I was somewhere like in Europe, and there was something like a tsunami, and I was on a cruise boat (like those we have in Russia), and trying to take the pictures of the thing. And then hiding in the basement of some office-like building…
Surprisingly, I just discovered there was an earthquake with a predicted 1 metre tsunami a few hours ago or so. http://news.yandex.ru/yandsearch?cl4url=www.ria.ru%2Fnatural%2F20120206%2F558210761.html
http://www.dslreports.com/forum/remark,26841639 Is at&t for real?
printf "%02x%02x:%02x%02x\n" 76 220 xx xx ; printf "%02x%02x:%02x%02x\n" 99 124 xxx xxx 4cdc:20yy 637c:YYYYFrom MSK.
# traceroute6 2602:304:cdc2:0yy0::1 ; traceroute6 2602:306:37cY:YYY0::1 traceroute6 to 2602:304:cdc2:0yy0::1 (2602:304:cdc2:yy0::1) from Z, 16 hops max, 12 byte packets Skipping 2 intermediate hops 3 xe012-438.RT.MR.MSK.RU.retn.net 1.320 ms 1.191 ms 1.248 ms 4 RT.TLX.NYC.US.retn.net 124.866 ms 124.400 ms 125.080 ms 5 as7018-att.10gigabitethernet2-3.core1.nyc4.he.net 137.598 ms 179.680 ms 150.144 ms 6 * * * 7 * * * 8 2001:1890:ff:ffff:12:122:99:125 139.270 ms 138.714 ms 138.885 ms 9 2602:300:c533:1510::4 138.903 ms 138.695 ms 138.780 ms 10 2602:300:c533:1510::5 189.738 ms 189.757 ms 190.096 ms 11 * * * 12 * * * 13 * * * 14 2602:300:c533:1510::5 190.810 ms 190.647 ms 190.884 ms traceroute6 to 2602:306:37cY:YYY0::1 (2602:306:37cY:YYY0::1) from Z, 16 hops max, 12 byte packets Skipping 2 intermediate hops 3 xe012-438.RT.MR.MSK.RU.retn.net 1.245 ms 1.090 ms 1.112 ms 4 RT.TLX.NYC.US.retn.net 124.698 ms 124.320 ms 124.783 ms 5 as7018-att.10gigabitethernet2-3.core1.nyc4.he.net 137.132 ms 137.704 ms 138.025 ms 6 * * * 7 * * * 8 2001:1890:ff:ffff:12:122:99:125 139.692 ms 140.326 ms 139.774 ms 9 2602:300:c533:1510::4 138.898 ms 139.584 ms 145.563 ms 10 2602:300:c533:1510::5 189.704 ms 190.298 ms 190.905 ms 11 * * * 12 2602:300:c533:1510::5 194.267 ms 192.703 ms 191.208 ms 13 * * * 14 * * * 15 2602:300:c533:1510::5 191.379 ms * 190.522 ms 16 * * *From FMT (at&t has a crappy route, but the routing definitely gets full trip to LA and safely back to the Bay Area).
# traceroute6 2602:304:cdc2:0yy0::1 ; traceroute6 2602:306:37cY:YYY0::1 traceroute to 2602:304:cdc2:0yy0::1 (2602:304:cdc2:yy0::1), 16 hops max, 80 byte packets 2 10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::1) 8.677 ms 8.680 ms 8.721 ms 3 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) 0.376 ms 0.427 ms 0.416 ms 4 10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2) 8.487 ms 8.496 ms 8.669 ms 5 10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2) 12.416 ms 12.880 ms 13.510 ms 6 att-internet4-as7018.10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::2) 9.267 ms 9.335 ms 9.417 ms 7 * * * 8 * * * 9 2001:1890:ff:ffff:12:122:114:41 (2001:1890:ff:ffff:12:122:114:41) 21.074 ms 21.109 ms 21.086 ms 10 2602:300:c533:1510::5 (2602:300:c533:1510::5) 20.761 ms 20.756 ms 20.812 ms 11 2602:300:c533:1510::5 (2602:300:c533:1510::5) 22.213 ms 21.943 ms 22.371 ms traceroute to 2602:306:37cY:YYY0::1 (2602:306:37cY:YYY0::1), 16 hops max, 80 byte packets 2 10gigabitethernet2-3.core1.fmt1.he.net (2001:470:1:1db::1) 0.536 ms 0.499 ms 0.443 ms 3 gige-g4-8.core1.fmt2.he.net (2001:470:0:2d::2) 4.335 ms 4.997 ms 4.995 ms 4 10gigabitethernet6-4.core1.lax1.he.net (2001:470:0:18d::2) 8.663 ms 8.649 ms 8.635 ms 5 10gigabitethernet1-3.core1.lax2.he.net (2001:470:0:72::2) 9.270 ms 9.617 ms 9.201 ms 6 att-internet4-as7018.10gigabitethernet5-2.core1.lax2.he.net (2001:470:0:1e6::2) 9.574 ms 9.549 ms 9.511 ms 7 * * * 8 * * * 9 2001:1890:ff:ffff:12:122:114:41 (2001:1890:ff:ffff:12:122:114:41) 21.208 ms 21.135 ms 21.165 ms 10 2602:300:c533:1510::5 (2602:300:c533:1510::5) 20.762 ms 20.773 ms 20.798 ms 11 * * * 12 * * * 13 * * * 14 * * * 15 2602:300:c533:1510::5 (2602:300:c533:1510::5) 22.326 ms 23.112 ms 22.765 ms 16 * * *Wow… … What’s next? Finally the 40/10 HSI for BPON subscribers? :-) Or 200/100 HSI with a GPON upgrade? (-:
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!
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