Archive for the 'FreeBSD' Category

pf.conf + pppoe 造成錯誤而無法載入 pf rule 的解法

如果遇到 PF + PPPOE 一起混著用的時候,又有 Lan connection ,有時候會開起來後 pf rule 完全沒被載入。這問題的起因就是,當 pf 先載入的時候 PPPOE client 還沒有把 daemon 跑起來,除了不知道 gateway 的 IP 外有可能連 Interface 都還沒出現。如果是 Interface 還沒出現的話,只要把該 interface (通常 pppoe 會是 tun0) 用括號包起來,像是:

ext_if_fttb=”tun0″
nat on $ext_if_fttb inet from $internal_net to {!$internal_net,!$sparq_net} -> ($ext_if_fttb)

這樣 pf 就不會檢查 $ext_if_fttb 是不是存在,而如果有用到 PPPOE 的 gateway 的話則可以換成:

gw_if_fttb=”(tun0:peer)”

這樣就不用每次重開完之後還要手動進去 pfctl -f /etc/pf.conf 了。

莫名其妙被婊

在 FreeBSD 7.1 PRELEASE 底下做比較複雜的網路環境,結果要讓 rsync + ssh 從其他網路跑進來撈備份的時候遇見很奇怪的問題:

明明就是通的,但是卻是慢到非常的誇張,比原先的線路還離譜。本來以為是 pf 擋到不該擋的,叫出 tcpdump 來看半天發現沒錯;又想說是不是走錯路,交叉測了很久也看不出啥端倪。最後比對正常跟有問題的 tcpdump 也看不出啥鬼。結果在對照[正常]組時發現:

02:52:39.274108 IP bad-len 0
02:52:39.304782 IP bad-len 0
02:52:39.334036 IP bad-len 0
02:52:39.335331 IP bad-len 0

這種東西,好奇 google 一下發現這篇,結果發現我也中大獎 -_-||

sysctl net.inet.tcp.tso=0

從此過著幸福快樂的日子……!@#$%^& …….

could not listen on UDP socket: permission denied

自從家裡的老 server 爆炸,然後應爹娘要求儘速處理,於是展開移山倒海 shift 大法,把比較省電且輕巧的小白 (AM2 X2 3800+) 給帶回去暫時先把網路搶通後就沒空理他,今天上去一看發現 message 一直出現:

May 9 04:19:11 soul named[960]: could not listen on UDP socket: permission denied
May 9 04:19:11 soul named[960]: creating IPv4 interface tun0 failed; interface ignored
May 9 05:19:11 soul named[960]: could not listen on UDP socket: permission denied
May 9 05:19:11 soul named[960]: creating IPv4 interface tun0 failed; interface ignored
May 9 06:19:11 soul named[960]: could not listen on UDP socket: permission denied
May 9 06:19:11 soul named[960]: creating IPv4 interface tun0 failed; interface ignored
May 9 07:19:11 soul named[960]: could not listen on UDP socket: permission denied
May 9 07:19:11 soul named[960]: creating IPv4 interface tun0 failed; interface ignored
May 9 08:19:11 soul named[960]: could not listen on UDP socket: permission denied
May 9 08:19:11 soul named[960]: creating IPv4 interface tun0 failed; interface ignored
May 9 09:19:11 soul named[960]: could not listen on UDP socket: permission denied

詢問了 google 大神之後發現大概是 這麼一回事 ,所以就乖乖的照著 mac_portacl(4) 去把 kernel configuration 的 options MAC 加進去,然後到 /boot/loader.conf 加入 mac_portacl_load=”YES” 接著照著 handbook 的 example 依樣畫葫蘆塞進 sysctl security.mac.portacl.rules=uid:53:udp:53,uid:53:tcp:53 然後重新啟動囉。

pf + smp + nogaint network stack = ?

剛剛看到大神這篇「升級到 6.1-RELEASE」裡面喊說因為腳踏車鎖(Giant lock)太多,所以就把 root server 衝到 6.1 了,真的是勇敢的長輩 XD。不過我是看到 GIANT LOCK 才想到我忘了說我遇到的狀況,所以才趕快來紀錄一下。

話說我家美人機到了之後總是會亂 panic 及亂七八糟的事情,在這一篇有稍微提到我後來換 ipnat 之後改善很多,不過偶爾還是會從網路上消失。後來大概在五月中的時候, 看到 mailing list 有人疑似有類似的情形,環境也是 smp ,後來過了不久某篇裡面談到:

This is very similar to the UID/GID filtering problem. What appears to
be happening is on the inbound path, we pickup the pfil lock and attempt
to pickup the inp info lock, while on the outbound path, we hold the inp
info lock across ip_output which will try to pickup the pfil lock.

This problem is the result of a layering violation, in reality the
firewall should not be picking up layer 4 related locks. Myself and a
few others have been discussing this problem for quite some time now,
and hopefully it won't be long before we can come up with a solution
that will make everyone happy.

For now, you should be able to set debug.mpsafenet to  0 which will
re-enable Giant in the network stack, in theory preventing the deadlock.

debug.mpsafenet=0

in your loader.conf

Let me know if this helps

 於是乎,測試了一下,把腳踏車鎖關掉,開機會看到:「WARNING: MPSAFE network stack disabled, expect reduced performance.」

Copyright (c) 1992-2006 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
        The Regents of the University of California. All rights reserved.
FreeBSD 6.1-STABLE #3: Wed May 17 22:41:10 CST 2006
    cookys@ddbeauty.iecs.us:/usr/obj/usr/src/sys/DDBEAUTY
WARNING: MPSAFE network stack disabled, expect reduced performance.
ACPI APIC Table: <GBT    AWRDACPI>
Timecounter "i8254" frequency 1193182 Hz quality 0
CPU: Intel(R) Pentium(R) D  CPU 2.66GHz (3340.93-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0xf47  Stepping = 7

 然後「感覺上」pf 好像反應比 ipnat 好,不過可能是錯覺 XD。雖然說腳踏車鎖一次就會綁一大堆,不過在會亂 dead lock 的狀況下也只能先打開撐著,看什麼時候他們解決 XD。至少跑到現在,兩個禮拜多都沒消失了,除了前一個禮拜被學校裝笑為把她 halt 等停電以外 :p

這時候該高呼,"捷安特鎖"我愛你嗎?(我沒有打廣告喔 @_@) 

eaccelerator + php5

剛剛在弄 mediawiki 才發現原來我家的 eaccelerator 根本一直都沒跑阿,花了一些時間看到底問題出在哪裡,發現原來是被擺到了。再安裝厚的提示訊息寫著:

*****************************************************************************

You have installed the eaccelerator package.

Edit %%LOCALBASE%%/etc/php.ini and add:

zend_extension="%%PREFIX%%/lib/php/%%PHP_EXT_DIR%%/eaccelerator.so"

Then create the cache directory:

mkdir /tmp/eaccelerator
chown www /tmp/eaccelerator
chmod 0700 /tmp/eaccelerator

*****************************************************************************

但是實際上如果去 /usr/local/etc/php.ini 設 zend_extension 事實上他會不理你。所以還是得設到 /usr/local/etc/php/extensions.ini 裡面去:

extension=eaccelerator.so 

本來是直接 copy/paste 他的路徑,結果 php -v 下去就又被 ooxx 。所以現在看起來,是真的有跑了:

PHP 5.1.4 (cli) (built: May  9 2006 10:48:26)
Copyright (c) 1997-2006 The PHP Group
Zend Engine v2.1.0, Copyright (c) 1998-2006 Zend Technologies
    with eAccelerator v0.9.5-beta2, Copyright (c) 2004-2006 eAccelerator, by eAccelerator

被 ports 的 hint message 擺道,很無言的阿!

PS. 前幾天  FreeBSD 的 php 好像地震了一下:

20060506:
  AFFECTS: users of PHP
  AUTHOR: ale@FreeBSD.org

  The old PHP slave ports (phpN-cli, phpN-cgi and mod_phpN) were removed
  in favour of unified PHP ports that allow building any combination of
  PHP SAPIs (cli, cgi and apache module).
  The PHP CGI binary was renamed to php-cgi, so you should update
  the path in your script. To simplify the update process, *only* for
  this release a 'php' compatibility symlink to php-cgi will be created
  if you don't select the CLI SAPI.
  Before the upgrade you *should* run 'make config' in lang/php4 or
  lang/php5 to configure the SAPIs you want to install.
  As a consequence the default binary packages include the CLI and the
  FastCGI SAPIs.
 

所以順手把他重新 make 了一次,進 php 打 make config 勾一勾然後 portupgrade -f 'php*' 下去就搞定了 :p