Re: 10.3-STABLE - PF - possible regression in pf.conf set timeout interval
For anyone stumbling here from google or wherever, Oliver has submitted a bug report and patches have been merged : https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=210924 This issue is closed. On 9 June 2016 at 12:01, Oliver Peter <li...@peter.de.com> wrote: > On Wed, May 11, 2016 at 09:44:32PM +0200, Damien Fleuriot wrote: > > On 11 May 2016 at 21:41, Luiz Otavio O Souza > wrote: > > > > > On Mon, May 9, 2016 at 12:15 PM, Kristof Provost wrote: > > > > > > > >> On 09 May 2016, at 16:58, Damien Fleuriot wrote: > > > >> > > > >> Since the upgrade, pf rules won't load anymore at boot time, nor > even > > > >> manually with pfctl -f /etc/pf.conf : > > > >> # pfctl -f /etc/pf.conf > > > >> /etc/pf.conf:24: syntax error > > > >> pfctl: Syntax error in config file: pf rules not loaded > > > >> > > > >> The problematic line is : > > > >> set timeout interval 10 > > > >> > > > > I think that was broken by the commit which added ALTQ support for > CoDel. > > > > > > > > It made ?interval? a keyword, and it looks like that breaks things > for > > > you. > > > > > > > > I?ve cced loos so he can take a look. > > > > > > Damien, > > > > > > I was AFK in the past couple days, I'll look at this tonight. > > > > > > Luiz > > > > > > > > > Cheers Luiz, > > > > Do tell if I may be of help, got a building box at work I can use just > for > > that ;) > > Hi, > > Is there any news on this? > We hit the problem today while applying our pf.conf from a 10.2 machine to > a 10.3-STABLE. Took a while to find out what actually happened to pf.conf > until a colleage found this thread. > Perhaps we should open a bug report for this? > > Cheers > ~ollie > > > -- > Oliver PETER oli...@gfuzz.de 0x456D688F > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 10.3-STABLE - PF - possible regression in pf.conf set timeout interval
On 11 May 2016 at 21:41, Luiz Otavio O Souza <loos...@gmail.com> wrote: > On Mon, May 9, 2016 at 12:15 PM, Kristof Provost wrote: > > > >> On 09 May 2016, at 16:58, Damien Fleuriot wrote: > >> > >> Since the upgrade, pf rules won't load anymore at boot time, nor even > >> manually with pfctl -f /etc/pf.conf : > >> # pfctl -f /etc/pf.conf > >> /etc/pf.conf:24: syntax error > >> pfctl: Syntax error in config file: pf rules not loaded > >> > >> The problematic line is : > >> set timeout interval 10 > >> > > I think that was broken by the commit which added ALTQ support for CoDel. > > > > It made ‘interval’ a keyword, and it looks like that breaks things for > you. > > > > I’ve cced loos so he can take a look. > > Damien, > > I was AFK in the past couple days, I'll look at this tonight. > > Luiz > Cheers Luiz, Do tell if I may be of help, got a building box at work I can use just for that ;) ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
10.3-STABLE - PF - possible regression in pf.conf set timeout interval
Hello list, == CONTEXT == I've upgraded 3 boxes from 10.3-PRERELEASE #13 (04/04/16) to 10.3-STABLE #17 (09/05/16) Dates in d/m/Y format. I'm afraid, since I use svnup, I cannot provide SVN revs. == PROBLEM DESCRIPTION == Since the upgrade, pf rules won't load anymore at boot time, nor even manually with pfctl -f /etc/pf.conf : # pfctl -f /etc/pf.conf /etc/pf.conf:24: syntax error pfctl: Syntax error in config file: pf rules not loaded The problematic line is : set timeout interval 10 == FURTHER TESTING == Values other than 10 also cause the issue. Tested using tabs or spaces, issue still arises. Commenting the line fixes the issue. == CONCLUSION == Displaying pf timers shows that the default 10s value is applied, when the configuration directive is commented from /etc/pf.conf : # pfctl -st | grep interval interval 10s Additionally, the "set timeout interval" directive still exists in man 5 pf.conf. This leads me to believe the directive should still be supported, and this may be an unintentional regression. Can anyone check if they also encounter the issue ? ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [POSSIBLE BUG] 10-STABLE CARP erroneously becomes master on boot
On 21 August 2015 at 09:06, Eugene M. Zheganin e...@norma.perm.ru wrote: Hi. On 20.08.2015 14:51, Damien Fleuriot wrote: Hello list, We've managed to find the source of the bug, if it is indeed a bug. It all comes down to the order in which the IP addresses are assigned to the interface from /etc/rc.conf. When using the following syntax, the physical IP address is configured AFTER the CARPs on the interface, which results in the CARP advertisements being sourced from the CARP IP, triggering the double MASTER situation : ipv4_addrs_int=1.2.3.4/24 ifconfig_int_alias0=1.2.3.6/32 vhid 1 pass test advskew 20 When using either of the following syntaxes, the physical IP address is configured BEFORE the CARPs, which results in the CARP advertisements being sourced from the physical IP and restoring normal functionality : ifconfig_int=inet 1.2.3.4/24 ifconfig_int_alias0=1.2.3.6/32 vhid 1 pass test advskew 20 OR ifconfig_int_alias0=1.2.3.4/24 ifconfig_int_alias1=1.2.3.6/32 vhid 1 pass test advskew 20 It has been there since carp-ng was commited to the 10-CURRENT 2 years ago. The thing is, carp-ng doesn't need a non-carp address on an interface anymore, both nodes can work fine using only shared address. This isn't comfortable in lots of cases, but still. Thus, kernel sends carp advertisements from a primary address on the interface (which is normal behavior for any known network stack) and for FreeBSD that primary address has always been the first address on an interface for a given AF. Thus, your split-brain carp situation cause lies definitely somewhere else. I'm running carp on FreeBSD for years, including legacy one; if there is a bug - the situation you are describing probably isn't one. Eugene, agree to disagree here. I've also been using CARP for years, both legacy and carp-ng, and while I'm not an expert on its inner workings I do understand how it operates. What you describe WRT the network stack and sourcing the advertisements is correct, I'll give you that. The problem lies not with CARP but with how the IP addresses are assigned by rc.conf It is abnormal that the CARP addresses should be set up first, when using the ipv4_addrs_int syntax. Therein lies the problem. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [POSSIBLE BUG] 10-STABLE CARP erroneously becomes master on boot
On 19 August 2015 at 18:20, Damien Fleuriot m...@my.gd wrote: On 19 August 2015 at 11:29, Damien Fleuriot m...@my.gd wrote: Hello list, Freddie, I've been able to run extensive tests, the results of which I'm pasting below. First of all, I've been unable to replicate the problem in our preproduction and QA environments. The differences between our production and pre/QA envs are as follows : - we use link aggregation and VLAN tagging in production , we cannot replicate this in pre/QA because of limitations with KVM guests. - we use multiple CARP addresses with the same VHID on our public VLAN in production, we COULD replicate that in pre/QA if required. The context remains the following : - host A is supposed to be CARP MASTER, has advskew 20 and preempt - host B is supposed to be CARP BACKUP, has advskew 150 and preempt - host B assumes mastership if the CARPs are configured from rc.conf , doesn't if they're set up manually after boot Note that these 2 boxes were upgraded from 8-STABLE to 10-STABLE. Host A runs 10.2-BETA1 Host B runs 10.2-PRERELEASE I used the exact same versions in our pre/QA environments (one BETA1, one PRERELEASE from the same build) and couldn't replicate the issue. Now, on to the tests themselves. A/ Create a new CARP address with a new VHID, configure it in rc.conf and see if we get double MASTERS - on Host A : CARP created manually - on Host B : CARP created manually Host A is MASTER and Host B is BACKUP - on Host B : setup the new CARP in rc.conf , reboot Host A is MASTER and Host B is BACKUP , problem not replicated B/ Try with only one of our production addresses - on Host B : uncomment the production CARP address from rc.conf , reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 C/ Try with the new CARP address + one of our production addresses , different VHIDs - on Host B : uncomment the new CARP address from rc.conf , reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 D/ Try the new syntax in rc.conf , as per Freddie's suggestion - on Host B : change the rc.conf syntax , reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 E/ Try, just for the sake of it, to remove old files and libs on host B - on Host B : cd /usr/src ; yes | make delete-old ; yes | make delete-old-libs ; reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 F/ Edit sysctls to disable CARP demotion on advertisement send errors - on Host A : sysctl net.inet.carp.senderr_demotion_factor=0 - on Host B : set net.inet.carp.senderr_demotion_factor=0 in sysctl.conf , reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 Now after this F/ test, I'm thinking there's some voodoo going on here and it sure shows up : - on Host A, 'pfctl -si' shows 3k states - on Host B, 'pfctl -si' shows 800 states Now that would explain why my CARP gets demoted on Host B (as per man 4 carp, pfsync failures result in a -240 demotion). It doesn't, however, explain why the demoted CARP chooses to remain in a MASTER state, or assumed MASTERship in the first place. Surely enough, I can find some CARP errors in-between my reboots : messages:2420:2015-08-19T03:51:38.273600+00:00 pf1-gs kernel: carp: demoted by -240 to 0 (pfsync bulk fail) messages:2429:2015-08-19T03:56:37.178575+00:00 pf1-gs kernel: carp: VHID 110@vlan410: INIT - BACKUP messages:2430:2015-08-19T03:56:40.664568+00:00 pf1-gs kernel: carp: VHID 110@vlan410: BACKUP - MASTER (master down) messages:2637:2015-08-19T04:00:22.482071+00:00 pf1-gs kernel: carp: VHID 111@vlan410: BACKUP - MASTER (master down) messages:2857:2015-08-19T04:04:02.330167+00:00 pf1-gs kernel: carp: VHID 110@vlan410: BACKUP - MASTER (master down) messages:2877:2015-08-19T04:05:03.288199+00:00 pf1-gs kernel: carp: demoted by -240 to 0 (pfsync bulk fail) messages:3088:2015-08-19T04:08:48.961985+00:00 pf1-gs kernel: carp: VHID 110@vlan410: BACKUP - MASTER (master down) Things I have not tested yet : - use /24 CARPs instead of /32s - switch my CARPs to all use different VHIDs Things I CANNOT test : - set up a *dedicated* pfsync link between the firewalls , they're in different DCs - set up a *dedicated* VLAN for pfsync , that would entail huge changes in our PCI-DSS environment After all these tests, I find myself in a situation where : - manually set up CARPs on Host B work fine , and pfsync works - CARPs from rc.conf on Host B result in MASTER-MASTER , and pfsync fails I must say I'm stuck here. The master down message is very confusing, when the firewalls *can* see each other. The pfsync bulk fail is rather interesting as well
Re: [POSSIBLE BUG] 10-STABLE CARP erroneously becomes master on boot
On 19 August 2015 at 11:29, Damien Fleuriot m...@my.gd wrote: Hello list, Freddie, I've been able to run extensive tests, the results of which I'm pasting below. First of all, I've been unable to replicate the problem in our preproduction and QA environments. The differences between our production and pre/QA envs are as follows : - we use link aggregation and VLAN tagging in production , we cannot replicate this in pre/QA because of limitations with KVM guests. - we use multiple CARP addresses with the same VHID on our public VLAN in production, we COULD replicate that in pre/QA if required. The context remains the following : - host A is supposed to be CARP MASTER, has advskew 20 and preempt - host B is supposed to be CARP BACKUP, has advskew 150 and preempt - host B assumes mastership if the CARPs are configured from rc.conf , doesn't if they're set up manually after boot Note that these 2 boxes were upgraded from 8-STABLE to 10-STABLE. Host A runs 10.2-BETA1 Host B runs 10.2-PRERELEASE I used the exact same versions in our pre/QA environments (one BETA1, one PRERELEASE from the same build) and couldn't replicate the issue. Now, on to the tests themselves. A/ Create a new CARP address with a new VHID, configure it in rc.conf and see if we get double MASTERS - on Host A : CARP created manually - on Host B : CARP created manually Host A is MASTER and Host B is BACKUP - on Host B : setup the new CARP in rc.conf , reboot Host A is MASTER and Host B is BACKUP , problem not replicated B/ Try with only one of our production addresses - on Host B : uncomment the production CARP address from rc.conf , reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 C/ Try with the new CARP address + one of our production addresses , different VHIDs - on Host B : uncomment the new CARP address from rc.conf , reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 D/ Try the new syntax in rc.conf , as per Freddie's suggestion - on Host B : change the rc.conf syntax , reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 E/ Try, just for the sake of it, to remove old files and libs on host B - on Host B : cd /usr/src ; yes | make delete-old ; yes | make delete-old-libs ; reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 F/ Edit sysctls to disable CARP demotion on advertisement send errors - on Host A : sysctl net.inet.carp.senderr_demotion_factor=0 - on Host B : set net.inet.carp.senderr_demotion_factor=0 in sysctl.conf , reboot Host A is MASTER and Host B is MASTER Host A shows net.inet.carp.demotion=0 Host B shows net.inet.carp.demotion=240 Now after this F/ test, I'm thinking there's some voodoo going on here and it sure shows up : - on Host A, 'pfctl -si' shows 3k states - on Host B, 'pfctl -si' shows 800 states Now that would explain why my CARP gets demoted on Host B (as per man 4 carp, pfsync failures result in a -240 demotion). It doesn't, however, explain why the demoted CARP chooses to remain in a MASTER state, or assumed MASTERship in the first place. Surely enough, I can find some CARP errors in-between my reboots : messages:2420:2015-08-19T03:51:38.273600+00:00 pf1-gs kernel: carp: demoted by -240 to 0 (pfsync bulk fail) messages:2429:2015-08-19T03:56:37.178575+00:00 pf1-gs kernel: carp: VHID 110@vlan410: INIT - BACKUP messages:2430:2015-08-19T03:56:40.664568+00:00 pf1-gs kernel: carp: VHID 110@vlan410: BACKUP - MASTER (master down) messages:2637:2015-08-19T04:00:22.482071+00:00 pf1-gs kernel: carp: VHID 111@vlan410: BACKUP - MASTER (master down) messages:2857:2015-08-19T04:04:02.330167+00:00 pf1-gs kernel: carp: VHID 110@vlan410: BACKUP - MASTER (master down) messages:2877:2015-08-19T04:05:03.288199+00:00 pf1-gs kernel: carp: demoted by -240 to 0 (pfsync bulk fail) messages:3088:2015-08-19T04:08:48.961985+00:00 pf1-gs kernel: carp: VHID 110@vlan410: BACKUP - MASTER (master down) Things I have not tested yet : - use /24 CARPs instead of /32s - switch my CARPs to all use different VHIDs Things I CANNOT test : - set up a *dedicated* pfsync link between the firewalls , they're in different DCs - set up a *dedicated* VLAN for pfsync , that would entail huge changes in our PCI-DSS environment After all these tests, I find myself in a situation where : - manually set up CARPs on Host B work fine , and pfsync works - CARPs from rc.conf on Host B result in MASTER-MASTER , and pfsync fails I must say I'm stuck here. The master down message is very confusing, when the firewalls *can* see each other. The pfsync bulk fail is rather interesting as well, since it doesn't occur when the CARPs are unconfigured, or set up
[patch] [ports] net/relayd config check in rc.d
Hello list, Does anyone want to take a look at https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=200914 ? This is a patch I submitted for net/relayd 's rc.d script so that it performs a configuration check before start/reload/restart, à la nginx. The ticket's been assigned to mm@ but it looks like he's not had the time to have a go at it. Note that the patch to the script was done on 8-STABLE but the script in 10-STABLE is identical. We've tested this in production and have yet to find issue with it. Cheers ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [POSSIBLE BUG] 10-STABLE CARP erroneously becomes master on boot
hasn't helped overmuch here, although I'll try some more. If anyone's got a pointer, I'll bite. Cheers On 17 August 2015 at 18:38, Damien Fleuriot m...@my.gd wrote: On 17 August 2015 at 18:32, Freddie Cash fjwc...@gmail.com wrote: On Aug 17, 2015 9:22 AM, Damien Fleuriot m...@my.gd wrote: Hello list, I'm seeing this very peculiar behaviour between 2 10-STABLE boxes. Host A is CARP Master with advskew 20 and runs 10.2-BETA1 from 10/07 Host B is CARP Backup with advskew 150 and runs 10.2-PRERELEASE from 12/08 When I configure CARP in rc.conf on host B, it becomes Master on boot, and host A remains Master as well. When I force a state change on host B (ifconfig vlanx vhid y state backup), it transitions to Backup then again to Master. When I comment out the CARP configuration in rc.conf , and configure CARP manually on host B's interfaces after it boots, it correctly becomes and remains Backup. Below is the excerpt from rc.conf pertaining to CARP configuration, the only difference between the 2 hosts being their advskew. Host A == BEGIN ifconfig_vlan410_alias0=vhid 110 pass passhere advskew 20 alias 10.104.10.251/32 == END Host B == BEGIN ifconfig_vlan410_alias0=vhid 110 pass passhere advskew 150 alias 10.104.10.251/32 == END Put the IP first, and the vhid stuff last in rc.conf for things to work the most reliably. And drop the extra alias. ifconfig_vlan410_alias0=inet 10.104.10.251/32 vhid 110 pass passhere advskew 150 CARP requires that all IPs on an interface that are part of the same vhid to be listed (added) in the exact same order for the vhid to be considered the same. That one trips me up all the time when manually adding an IP to a CARP pair, and then later rebooting one box as they both think they're master for that interface, while being a mix of master/backup for the other interfaces. Cheers, Freddie (running CARP on 2 10-CURRENT boxes and 2 10.1-p13 boxes) Cheers Freddie, will try and keep the thread up to date on the results. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [POSSIBLE BUG] 10-STABLE CARP erroneously becomes master on boot
On 17 August 2015 at 18:32, Freddie Cash fjwc...@gmail.com wrote: On Aug 17, 2015 9:22 AM, Damien Fleuriot m...@my.gd wrote: Hello list, I'm seeing this very peculiar behaviour between 2 10-STABLE boxes. Host A is CARP Master with advskew 20 and runs 10.2-BETA1 from 10/07 Host B is CARP Backup with advskew 150 and runs 10.2-PRERELEASE from 12/08 When I configure CARP in rc.conf on host B, it becomes Master on boot, and host A remains Master as well. When I force a state change on host B (ifconfig vlanx vhid y state backup), it transitions to Backup then again to Master. When I comment out the CARP configuration in rc.conf , and configure CARP manually on host B's interfaces after it boots, it correctly becomes and remains Backup. Below is the excerpt from rc.conf pertaining to CARP configuration, the only difference between the 2 hosts being their advskew. Host A == BEGIN ifconfig_vlan410_alias0=vhid 110 pass passhere advskew 20 alias 10.104.10.251/32 == END Host B == BEGIN ifconfig_vlan410_alias0=vhid 110 pass passhere advskew 150 alias 10.104.10.251/32 == END Put the IP first, and the vhid stuff last in rc.conf for things to work the most reliably. And drop the extra alias. ifconfig_vlan410_alias0=inet 10.104.10.251/32 vhid 110 pass passhere advskew 150 CARP requires that all IPs on an interface that are part of the same vhid to be listed (added) in the exact same order for the vhid to be considered the same. That one trips me up all the time when manually adding an IP to a CARP pair, and then later rebooting one box as they both think they're master for that interface, while being a mix of master/backup for the other interfaces. Cheers, Freddie (running CARP on 2 10-CURRENT boxes and 2 10.1-p13 boxes) Cheers Freddie, will try and keep the thread up to date on the results. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CARp comatibility between 9 and 10
On 8 June 2015 at 12:13, Pete French petefre...@ingresso.co.uk wrote: I did this a while ago - and it actually worked. (CARP between 9 and 10). I think I have each IP assigned its own VHID, though. Thanks for this, someone else has confimred that 10 orks with multiple IP's per VHID, so I am good to go. Do I still need to compile a separate kernel with pfsync and carp in it, or can these now be loaded as modules ? I cant remember when I started doing that, but I suspect it may no longer be necessary. OK I'm late to reply to this, but a word of caution to those that would upgrade from 8 to 10 or 9 to 10. While CARP maintains compatibility between the two different OS releases, you will lose pfsync capability. That means when you switch over your CARP master, PF will drop all these sessions that existed at host A but were not synched over to host B. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
[POSSIBLE BUG] 10-STABLE CARP erroneously becomes master on boot
Hello list, I'm seeing this very peculiar behaviour between 2 10-STABLE boxes. Host A is CARP Master with advskew 20 and runs 10.2-BETA1 from 10/07 Host B is CARP Backup with advskew 150 and runs 10.2-PRERELEASE from 12/08 When I configure CARP in rc.conf on host B, it becomes Master on boot, and host A remains Master as well. When I force a state change on host B (ifconfig vlanx vhid y state backup), it transitions to Backup then again to Master. When I comment out the CARP configuration in rc.conf , and configure CARP manually on host B's interfaces after it boots, it correctly becomes and remains Backup. Below is the excerpt from rc.conf pertaining to CARP configuration, the only difference between the 2 hosts being their advskew. Host A == BEGIN ifconfig_vlan410_alias0=vhid 110 pass passhere advskew 20 alias 10.104.10.251/32 == END Host B == BEGIN ifconfig_vlan410_alias0=vhid 110 pass passhere advskew 150 alias 10.104.10.251/32 == END Additionally, the sysctls for CARP for both boxes : == BEGIN net.inet.carp.ifdown_demotion_factor: 240 net.inet.carp.senderr_demotion_factor: 240 net.inet.carp.demotion: 0 net.inet.carp.log: 1 net.inet.carp.preempt: 1 net.inet.carp.allow: 1 net.pfsync.carp_demotion_factor: 240 == END The hosts can see each other correctly, as evidenced by manually configuring the CARP aliases on Host B after it boots, and it retaining Backup status. Has anyone experienced the same problem ? I'm thinking of upgrading Host A to 10.2-PRERELEASE so they're on the same revision level, but I'm afraid it may break CARP on boot as on Host B. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: svn - but smaller?
On 13 Mar 2013, at 06:29, Ian Smith smi...@nimnet.asn.au wrote:
On Tue, 12 Mar 2013 18:32:28 -0500, John Mehr wrote:
On Tue, 12 Mar 2013 02:20:37 +0100
Michael Ross g...@ross.cx wrote:
On Tue, 12 Mar 2013 00:15:35 +0100, John Mehr j...@visi.com wrote:
[..]
Hello,
I'm currently in the process of adding http/https support to svnup and
once I've got that working, the command line interface will be changing
to be more like the traditional svn client to make it easier for people
to adopt the tool [...]
What'd you think about a syntax extension along the lines of
svnup --bsd-base
svnup --bsd-ports
svnup --bsd-all
with automagic host selection, default to uname's major version stable
branch and default target dirs?
Hello,
This sounds good to me, and as long as there's some sort of a consensus that
we're not breaking the principle of least surprise, I'm all for it. The one
default that may be unexpected is the defaulting to the stable branch --
people who track the security branches will be left out. So maybe something
like:
svnup --ports
svnup --stable
svnup --security (or --release)
Thoughts?
Hi John,
I have a few ..
Firstly, this is a great advance for I suspect many people who aren't
developers as such, but want to simply update sources for some or all of
the reasons Ike spells out on his wiki page. The sooner this hits the
tree the better in my view, but adding more features won't speed that.
I have a small test system on which I'd installed (two instances of) 9.1
so a couple of days ago I fetched ports with portsnap, installed svnup,
and ran it using the (just what I needed) example command in svnup(1).
I get about 700KB/s here, and svnup took about 15 minutes to update 9.1
sources to 9-stable. This is fine. Last night I ran it again, but it
took 12:42 to make no changes. This seemed puzzling, as you'd said only
a few minutes for subsequent updates, but the reason appears to be that
in both cases, I ran it in script(1), and the default verbosity of 1
includes a listing of every directory and file examined, followed by
CR then erase to eol codes. Even in less -r (raw) mode it still has
to display and skip through all the (now invisible) lines; bit messy.
Even the second do-nothing run made a 2MB script file, the original with
all 9.1 to -stable updates being 3.4MB. So I'd love the option to only
list the changes (- and +) and simply ignore unchanged dirs/files
without any display for use in script(1). Apart from that, I'm happy.
As is, it more or less follows csup(1) type arguments, and I think that
as a c{,v}sup replacement that's appropriate. Making its arguments more
like svn's may actually be confusing, if it leads people to think of it
as svn light when it really isn't, especially with no .svn directory.
As we have portsnap, which updates INDEX-* and checks integrity, I'm not
sure that using svnup for ports is worthwhile considering. It would
save (here) 135MB in var/db/portsnap, but that's pretty light in view of
the 700MB-odd of /usr/ports/.svn in the ports distributed with 9.1-R
I beg to differ, if I can only use the tool to upgrade my base sources but not
the ports, thus still needing vanilla SVN, then I for one won't have any use
for said tool whatsoever.
Just my take on it.
I'm totally not into portsnap.
As for stable, release or security branches (of which major release?) I
think specifying base/stable/9 or whatever is good; it helps people with
10 or more years of 9-STABLE or 9.1-RELEASE etc syntax adapt to the svn
reality but remains explicit enough to put in a script and know just
what's being fetched, without regard to the fetching machine's uname.
Not to go as far as emulating supfiles, but a few things (host, branch
and target dir) would be useful in a small .conf file that could be
specified on command line, as a supfile is to csup, perhaps?
And svnup(1) really should mention that any files in the target tree not
in the repository will be deleted, which was (explicitly) not the case
with c{,v}sup. I only lost a few acpi patches that I think have likely
made it to stable/9 anyway, and it's a test system, but I was surprised.
All the best John; as a first contribution I think this is fabulous!
cheers, Ian
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ask about stable
On 20 Feb 2013, at 06:03, Nurhermansyah eka ekanoti...@gmail.com wrote: hi all.. if I could make a stable version for freebsd 9.1-release ?? thanks Hi, Did you mean I'm running 9.1-RELEASE and I want to update it to 9-STABLE ? If not, kindly clarify... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
SOLVED Re: messed up my ports somehow
Glad I could help :) On 20 Feb 2013, at 21:00, Craig Yoshida crai...@scripps.edu wrote: fixed you, sir, are a rock star. --- Craig Yoshioka, Ph.D. (619) 623-2233 (cell) The Scripps Research Institute 10550 N. Torrey Pines Rd. La Jolla, CA 92037 On Feb 20, 2013, at 11:24 AM, Fleuriot Damien m...@my.gd wrote: Then, I'm taking a wild guess at what I think is happening. You have WITH_PKGNG=yes in /etc/make.conf Your portmaster is built without the PKGNG patch. Would you go to /usr/ports/ports-mgmt/portmaster/ then issue 'make config' If I'm right, you're only missing the patch, tick the option and issue: make clean make make deinstall make reinstall On Feb 20, 2013, at 8:22 PM, Craig Yoshida crai...@scripps.edu wrote: pkg_info lists no packages pkg info seems to list them all. --- Craig Yoshioka, Ph.D. (619) 623-2233 (cell) The Scripps Research Institute 10550 N. Torrey Pines Rd. La Jolla, CA 92037 On Feb 20, 2013, at 11:15 AM, Fleuriot Damien m...@my.gd wrote: What about either of these 2 ? pkg_info pkg info On Feb 20, 2013, at 8:14 PM, Craig Yoshioka crai...@nanoimagingservices.com wrote: I was having problems with broken missing dependencies, etc. Long story short I fixed it by wiping a lot of stuff and reinstalling it, but now portmaster does not seem to be working. running portmaster -l lists none of the installed ports. Any ideas on how to fix it? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pkg can't access pkgbeta.freebsd.org
: in the URL instead of / , possibly ? I find it strange that there should be : in the URL, it is only acceptable when denoting the destination port to connect to. Try replacing them with slashes. -- Sent from my [insert random phone here] On 6 Feb 2013, at 12:59, Marek Salwerowicz marek_...@wp.pl wrote: Hi, On freshly installed FreeBSD-9.1-Release amd64 (from ISO) I am trying to migrate to new generation of packages: arch1% sudo pkg The package management tool is not yet installed on your system. Do you want to fetch and install it now? [y/N]: y Bootstrapping pkg please wait pkg: Error fetching http://pkgbeta.FreeBSD.org/freebsd:9:x86:64/latest/Latest/pkg.txz: No route to host arch1% arch1% traceroute pkgbeta.freebsd.org traceroute to bwwwdyn.freebsd.org (69.147.83.39), 64 hops max, 52 byte packets 1 172.16.30.1 (172.16.30.1) 1.215 ms 1.106 ms 1.107 ms 2 192.168.0.99 (192.168.0.99) 2.337 ms 2.474 ms 1.933 ms 3 pw-gw-gi3-0-558.warman.nask.pl (194.181.61.225) 3.978 ms 5.550 ms 4.799 ms 4 172.27.27.2 (172.27.27.2) 5.524 ms 5.292 ms 6.841 ms 5 frankfurt-gw-ae1-100.core.nask.pl (195.187.255.183) 29.989 ms 39.843 ms 28.430 ms 6 ge-1-3-0.pat2.dee.yahoo.com (80.81.193.115) 28.565 ms 28.384 ms 28.221 ms 7 as-1.pat2.dcp.yahoo.com (66.196.65.129) 119.239 ms 119.011 ms 118.605 ms 8 as-0.pat2.da3.yahoo.com (216.115.101.155) 193.173 ms 198.485 ms ae-7.pat2.che.yahoo.com (216.115.100.137) 224.062 ms 9 ae-6.pat1.dnx.yahoo.com (216.115.96.207) 191.784 ms as-1.pat2.sjc.yahoo.com (216.115.101.151) 194.342 ms ae-5.pat2.dnx.yahoo.com (216.115.96.55) 186.775 ms 10 ae-7.pat1.sjc.yahoo.com (216.115.101.149) 189.467 ms ae-7.pat1.pao.yahoo.com (216.115.101.128) 183.305 ms ae-7.pat1.sjc.yahoo.com (216.115.101.149) 192.312 ms 11 ae-0-d141.msr1.sp1.yahoo.com (216.115.107.51) 186.679 ms ae-1-d170.msr2.sp1.yahoo.com (216.115.107.85) 221.705 ms ae-1-d160.msr1.sp1.yahoo.com (216.115.107.61) 185.266 ms 12 * gi-1-47.bas-b1.sp1.yahoo.com (209.131.32.45) 187.202 ms gi-1-33.bas-b2.sp1.yahoo.com (98.136.16.33) 184.560 ms 13 * * * 14 * * * 15 * * * 16 * * * 17 * * * 18 * * * 19 * * * 20 * * * 21 * * * 22 * * * 23 * *^C arch1% ping pkgbeta.freebsd.org PING bwwwdyn.freebsd.org (69.147.83.39): 56 data bytes and no answer... Regards, -- Marek Salwerowicz ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: bge bad performance
On 25 Jan 2013, at 11:45, Daniel Braniss da...@cs.huji.ac.il wrote: Hi, It seems that I have more issues with the bge, Broadcom NetXtreme Gigabit Ethernet, ASIC rev. 0x572 ifconfig says: bge2: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=c019bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,VLAN_HWTS O,LINKSTATE ether xx... inet6 xxx prefixlen 64 scopeid 0x3 inet xxx... netmask 0xf000 broadcast yyy nd6 options=21PERFORMNUD,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active iperf reports [ 3] 0.0-10.0 sec 230 MBytes 193 Mbits/sec Post your iperf command line and explain the test environment, as in direct connection vs switched network link ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PF Configuration - FreeBSD Release 9.0 x64
On 11 Sep 2012, at 10:15, Shiv. Nath prabh...@digital-infotech.net wrote: Dear FreeBSD Guys, It is FreeBSD Release 9.0 x64 and i see this log very frequent almost every second, And i want to block this IP from reaching my server. i configured the PF as following but still see the same logs, it is like it did not work. block in log quick from 41.211.2.239/32 to any Sep 11 07:49:56 titan avahi-daemon[1567]: Received response from host 41.211.2.239 with invalid source port 4331 on interface 'em0.0' Sep 11 07:50:25 titan avahi-daemon[1567]: Received response from host 41.211.2.239 with invalid source port 38627 on interface 'em0.0' Sep 11 07:51:29 titan avahi-daemon[1567]: Received response from host 41.211.2.239 with invalid source port 38627 on interface 'em0.0' ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org It says it received a *response* so my understanding is *you* are trying to connect. Adjust your rule and see if it's any better.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem with link aggregation + sshd
Hi Giulio, Just to clear things up: igb0: 192.168.9.60/24 lagg0: 192.168.12.21/24 What's the IP of the host you're trying ssh connections from ? Also, just in case, did you enable any firewall ? (PF, ipfw) On 27 August 2012 21:22, Giulio Ferro au...@zirakzigil.org wrote: Hi, thanks for the answer Here is what you asked for: # ifconfig igb0 igb0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=4401bbRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,VLAN_HWTSO ether ... inet 192.168.9.60 netmask 0xff00 broadcast 192.168.9.255 inet6 prefixlen 64 scopeid 0x1 nd6 options=29PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL media: Ethernet autoselect (1000baseT full-duplex) status: active # netstat -rn Routing tables Internet: DestinationGatewayFlagsRefs Use Netif Expire default192.168.9.1UGS 00 igb0 127.0.0.1 link#12UH 00lo0 192.168.9.0/24 link#1 U 0 14 igb0 192.168.9.60 link#1 UHS 00lo0 192.168.12.0/24link#13U 0 109 lagg0 192.168.12.21 link#13UHS 00lo0 Internet6: Destination Gateway Flags Netif Expire ::/96 ::1 UGRS lo0 ::1 link#12 UH lo0 :::0.0.0.0/96 ::1 UGRS lo0 fe80::/10 ::1 UGRS lo0 fe80::%igb0/64link#1Uigb0 fe80::ea39:35ff:feb6:a0d4%igb0link#1UHS lo0 fe80::%igb1/64link#2Uigb1 fe80::ea39:35ff:feb6:a0d5%igb1link#2UHS lo0 fe80::%igb2/64link#3Uigb2 fe80::ea39:35ff:feb6:a0d6%igb2link#3UHS lo0 fe80::%igb3/64link#4Uigb3 fe80::ea39:35ff:feb6:a0d7%igb3link#4UHS lo0 fe80::%lo0/64 link#12 U lo0 fe80::1%lo0 link#12 UHS lo0 fe80::%lagg0/64 link#13 U lagg0 fe80::ea39:35ff:feb6:a0d5%lagg0 link#13 UHS lo0 ff01::%igb0/32fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 ff01::%igb1/32fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 ff01::%igb2/32fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 ff01::%igb3/32fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 ff01::%lo0/32 ::1 U lo0 ff01::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U lagg0 ff02::/16 ::1 UGRS lo0 ff02::%igb0/32fe80::ea39:35ff:feb6:a0d4%igb0 U igb0 ff02::%igb1/32fe80::ea39:35ff:feb6:a0d5%igb1 U igb1 ff02::%igb2/32fe80::ea39:35ff:feb6:a0d6%igb2 U igb2 ff02::%igb3/32fe80::ea39:35ff:feb6:a0d7%igb3 U igb3 ff02::%lo0/32 ::1 U lo0 ff02::%lagg0/32 fe80::ea39:35ff:feb6:a0d5%lagg0 U lagg0 # netstat -aln | grep 22 tcp40 0 *.22 *.* LISTEN tcp60 0 *.22 *.* LISTEN Note that I already tried to only listen on igb0 interface (192.168.9.60) in sshd_config, but the results are exactly the same described below. On 08/25/2012 01:22 PM, Damien Fleuriot wrote: In the meantime kindly post: Ifconfig for your igb0 Netstat -rn Netstat -aln | grep 22 On 25 Aug 2012, at 13:18, Damien Fleuriot m...@my.gd wrote: I'll get back to you regarding link aggregation when I'm done with groceries. We use it here in production and it works flawlessly. On 25 Aug 2012, at 09:54, Giulio Ferro au...@zirakzigil.org wrote: No answer, so it seems that link aggregation doesn't really work in freebsd, this may help others with the same problem... I reverted back to one link for management and one for service, and ssh works as it should... On 08/21/2012 11:18 PM, Giulio Ferro wrote: Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) 1 nic is connected standalone to the management switch, the 3 other nics are connected to a switch configured for aggregation. If I configure the first nic (igb0) there is no problem, I can operate as I normally do and sshd functions normally. The problems start when I configure the 3 other nics
Re: Problem with link aggregation + sshd
I'll get back to you regarding link aggregation when I'm done with groceries. We use it here in production and it works flawlessly. On 25 Aug 2012, at 09:54, Giulio Ferro au...@zirakzigil.org wrote: No answer, so it seems that link aggregation doesn't really work in freebsd, this may help others with the same problem... I reverted back to one link for management and one for service, and ssh works as it should... On 08/21/2012 11:18 PM, Giulio Ferro wrote: Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) 1 nic is connected standalone to the management switch, the 3 other nics are connected to a switch configured for aggregation. If I configure the first nic (igb0) there is no problem, I can operate as I normally do and sshd functions normally. The problems start when I configure the 3 other nics for aggregation: in /etc/rc.conf ... ifconfig_igb1=up ifconfig_igb2=up ifconfig_igb3=up cloned_interfaces=lagg0 ifconfig_lagg0=laggproto lacp laggport igb1 laggport igb2 laggport igb3 192.168.12.7/24 ... I restart the server and the aggregation seems to work correctly, in fact ifconfig returns the correct lagg0 interface with the aggregated links, the correct protocol (lacp) and the correct ip address and the status is active. I can ping other IPs on the aggregated link. Also the other (standalone) link seems to work correctly. I can ping that address from other machines, and I can ping other IPs from that server. DNS lookups work ok too I can also use telnet to connect to pop3 servers so there seems to be no problem on the network stack. But if I try to connect to the sshd service on that server, it hangs indefinitely. On the server I find two sshd processes: /usr/sbin/sshd /usr/sbin/sshd -R There is no message in the logs. If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays there forever waiting for the pid to die (it never does) Even ssh client doesn't seem to work. In fact, if I try to connect to another server, the ssh client may start to work correctly, then soon or later it just hangs there forever, and I can't kill it with ctrl-c. No firewall is configured, there is nothing else working on this server. Thanks for any suggestions... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Problem with link aggregation + sshd
In the meantime kindly post: Ifconfig for your igb0 Netstat -rn Netstat -aln | grep 22 On 25 Aug 2012, at 13:18, Damien Fleuriot m...@my.gd wrote: I'll get back to you regarding link aggregation when I'm done with groceries. We use it here in production and it works flawlessly. On 25 Aug 2012, at 09:54, Giulio Ferro au...@zirakzigil.org wrote: No answer, so it seems that link aggregation doesn't really work in freebsd, this may help others with the same problem... I reverted back to one link for management and one for service, and ssh works as it should... On 08/21/2012 11:18 PM, Giulio Ferro wrote: Scenario : freebsd 9 stable (yesterday) amd64 on HP server with 4 nic (igb) 1 nic is connected standalone to the management switch, the 3 other nics are connected to a switch configured for aggregation. If I configure the first nic (igb0) there is no problem, I can operate as I normally do and sshd functions normally. The problems start when I configure the 3 other nics for aggregation: in /etc/rc.conf ... ifconfig_igb1=up ifconfig_igb2=up ifconfig_igb3=up cloned_interfaces=lagg0 ifconfig_lagg0=laggproto lacp laggport igb1 laggport igb2 laggport igb3 192.168.12.7/24 ... I restart the server and the aggregation seems to work correctly, in fact ifconfig returns the correct lagg0 interface with the aggregated links, the correct protocol (lacp) and the correct ip address and the status is active. I can ping other IPs on the aggregated link. Also the other (standalone) link seems to work correctly. I can ping that address from other machines, and I can ping other IPs from that server. DNS lookups work ok too I can also use telnet to connect to pop3 servers so there seems to be no problem on the network stack. But if I try to connect to the sshd service on that server, it hangs indefinitely. On the server I find two sshd processes: /usr/sbin/sshd /usr/sbin/sshd -R There is no message in the logs. If I try to kill sshd (/etc/rc.d/sshd stop) I can't. it just stays there forever waiting for the pid to die (it never does) Even ssh client doesn't seem to work. In fact, if I try to connect to another server, the ssh client may start to work correctly, then soon or later it just hangs there forever, and I can't kill it with ctrl-c. No firewall is configured, there is nothing else working on this server. Thanks for any suggestions... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Compiling 8.3 kernel
On 7/23/12 2:37 PM, Gót András wrote: Dear All, In the weekend I tried to compile a custom AMD64 8.3 kernel. It started as a normal buildworld + buildkernel update from 8.3 and it turned out that without the FREEBSD_COMPAT6 and maybe LIB32 kernel config option the system won't boot into multiuser. It was mount and something else that crashed with a sig11 and therefore I left in single user mode. Somehow I left FREEBSD_COMPAT7 also in the config, but I'd sort that out also if possible. Of course the machine booted with the GENERIC kernel even after installworld which went fine in single user mode. I've found the following in the handbook, regarding the : This option is required to support applications compiled on FreeBSD 6.X versions that use FreeBSD 6.X system call interfaces. I thought it won't be needed by default. There's nothing special in the kernel config file. I just sorted out unwanted devices (e.g: bluetooth, wifi, non-gbit nics etc.) and options from the GENERIC config file. If the new config or any other machine details needed please let me know. Regards, Andras Got Keep the COMPAT options to avoid running into problems. Also, regarding the customization of configuration files, see this article from Warren Block: http://www.wonkity.com/~wblock/docs/html/kernelconfig.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Intel X520-DA2 Supported in stable/8?
On 22 Jun 2012, at 22:02, Rick Miller vmil...@hostileadmin.com wrote: On Fri, Jun 22, 2012 at 3:54 PM, Andrew Boyer abo...@averesystems.com wrote: The ixgbe driver creates devices named ix0, etc. I believe you need to run 'ifconfig ix0 up' before it will attempt to get link. Thanks for clarifying that tidbit. At least I know the driver loading is the correct driver :) I did try ifup'ing the interface...it shows the interface up, status is still no carrier. I've had confirmation that the cable itself is good. I wonder if it matters that the upstream switch has VLAN tagging enabled? Nope, having a link is layer 1, VLAN tagging happens at layer 3 iirc. If you're unsure, you can always create a VLAN interface bound to your NIC. I suppose you've tried reversing the fibre pair.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: su problem
On 6/10/12 1:52 PM, Daniel Braniss wrote: Sami Halabi sodyn...@gmail.com wrote: Hi Oliver, I saw you had similar problem for console on 2010 http://freebsd.1045724.n5.nabble.com/Serial-console-problems-with-stab=le-8-td3950684.html No, I don't think that the problem is related. My problem was with the serial console, while you don't have a serial console attached at all (at least you didn't mention it). but the thread wasn't ended by recommendation or conclusions by you. did you solve that problem then? No, I came to the conclusion that the serial console support in FreeBSD 8 was broken somehow. So I removed the console cable; it's running with an old VGA CRT as the console for now. Fortunately I require console access very seldom, so I don't have to drive to that machine often. It's still annoying, but I didn't find a better solution; downgrading to 7.x isn't an option. just for the record, serial on 8.x works fine! the device naming has changed from sio to uart, and maybe some features. We use it on all our servers, even redirecting it where possible via ILO,IMPI,DRAC. and is great for debuging or saving long trips :-) WARNING: control access to these devices, specialy since root can login on the console! danny Daniel, would you kindly elaborate on the DRAC console redirection thingy ? We're using Dells here and I loathe having to use their web interface and the java app to get a console shell. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: su problem
On 6/9/12 9:55 AM, Sami Halabi wrote: Hi, I Just finished upgrade from FBSD-8.1-R fresh system to FBSD-8.3-p2. once done, i created regular accounts, in wheel group. first all was okay, but suddenly i found my self blocked out, because i can't ssh as root, and i can't su either, when i su i get this: %su - Password: and it stuck in that state whitout givving me root shell #. any ideas how to solve this problem? the system is in the servers farm and i need to drive 3 hours each direction, so if there is remote solution i would appreciate it. %more /etc/group # $FreeBSD: src/etc/group,v 1.35.10.2.2.1 2012/03/03 06:15:13 kensmith Exp $ # wheel:*:0:root,sody . . . sody:*:1001: Thanks in advance, Ok so, I've read all the replies so far and I'm a bit perplexed. Sami, before you drive 3 hours to and 3 hours fro, kindly log in as sody over SSH, then try login to connect *locally* as the root user. If that works, you'll at least have recovered root access and will be able to install sudo, which should help you a great deal. Of course there's still the matter of finding what's wrong with your machine, afterwards. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPv6 and CARP crashes boxes
On 6/12/12 2:48 PM, Pete French wrote: Meant to reply to this at the time, but have been away... Has anyone else run into problems when using IPv6 + CARP ? I ran into some - aliases on a CARP integface did not seem to work proprly - but if you workaround that then it appears to work fine. We are using it in production with no problems. I plan to hold a presentation at work on IP6 and why we should start using it, however I cannot promote the use of IP6 without redundancy between firewalls like we currently do with CARP + pfsync. The redundancy with pfsync works properly - an ssh session is maintained through the firewalls when they failover. I configure my machines to use a paiur of carp interfaces on each physical port, so I am not mixing IPv4 and IPv6 on the same interface. I onyl did that as an experiment when I was trying to work around the aliases problem, but have kept it for tidnyess Basically our experience of the setup has been very positive - our main connectivity issues have come from the HE/Cogent peering squabble rather than any FreeBSD/Carp/PF failing. cheers, -pete. Thanks for the feedback Pete, what are you running ? We're on 8-STABLE here. I've got some spare time on my hands actually, I'm gonna try some more today, both on an ipv6-only carp, then on a v4+v6. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: su problem
On 6/12/12 3:00 PM, Oliver Fromme wrote: Damien Fleuriot m...@my.gd wrote: Ok so, I've read all the replies so far and I'm a bit perplexed. Sami, before you drive 3 hours to and 3 hours fro, kindly log in as sody over SSH, then try login to connect *locally* as the root user. That won't work. Unless you've disabled the securetty check in /etc/pam.d/login, but it is there for a reason. Best regards Oliver Aw :( With a bit of luck, anything that would just start a command without trying for an actual shell ? Perhaps su -m root -c 'cd /etc/ssh/ sed -i .bak -e s/PermitRootLogin no/PermitRootLogin yes/' ? That way he could toggle remote root logins. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPv6 and CARP crashes boxes
On 6/12/12 3:03 PM, Pete French wrote: Thanks for the feedback Pete, what are you running ? We're on 8-STABLE here. Yup, same here - aactually running a very recent STABLE now, but for most of this year it's been on one from January. The one running on the firewalls is from May 7th, and that works beautifully. Hmmm you might want to update again then, 2 SAs published late in may: http://security.freebsd.org/advisories/FreeBSD-SA-12:01.openssl.asc http://security.freebsd.org/advisories/FreeBSD-SA-12:02.crypt.asc I've got some spare time on my hands actually, I'm gonna try some more today, both on an ipv6-only carp, then on a v4+v6. Ok, let us know how you get on - the config here is very simple, reproduced below for your viewing pleasure ;) This is from the 'active' firewall: ifconfig_em0=inet 10.32.10.1/16 ipv6_ifconfig_em0=2a02:1658:1:2:a32f::1/64 ifconfig_em1=inet 178.250.73.196/27 ipv6_ifconfig_em1=2a02:1658:1:1::1:2/64 ifconfig_carp0=vhid 10 pass 10.32.10.6/16 ifconfig_carp1=vhid 20 pass 178.250.73.198/27 ipv6_ifconfig_carp2=vhid 30 pass 2a02:1658:1:2:a32f::6/64 ipv6_ifconfig_carp3=vhid 40 pass 2a02:1658:1:1::1:1/64 -pete. Thanks, will keep the thread updated ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPv6 and CARP crashes boxes
On 6/12/12 3:05 PM, Adam Strohl wrote: On 6/12/2012 19:48, Pete French wrote: I ran into some - aliases on a CARP integface did not seem to work proprly - but if you workaround that then it appears to work fine. We are using it in production with no problems. I have noticed this issue (CARP + IPv4 aliases) with older (pre 9.x) versions of FreeBSD. I maintain some legacy 6.2 servers and had to eventually add ifconfig statements inside rc.local to get the links to coalesce. 6.2 appears to ignore _aliasn directives entirely inside rc.conf, and has real issues if you add/delete aliases to a CARP interface while its up (both peers end up thinking they're MASTER). In 9.x it all works as expected at least for IPv4 (rc.conf carpn_aliasn entries, aliases, on the fly reconfiguring). Like Pete, we haven't experienced problems related to aliases either here. Running on a variety of 8.1-RELEASE , 8.2-PRERELEASE, 8.2-RELEASE, and now thankfully 8.3-STABLE ;) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: GCC-4.6-20120608 has a corrupt archive or a bad checksum
On 6/12/12 7:04 PM, Gerald Pfeifer wrote: John Merryweather Cooper wrote: Bad distfile or checksum for lang/gcc46 The mirror you are using per your e-mail -- ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/sources.redhat.com/ -- provides a broken image. I have done several downloads myself, from the original source and other mirrors, and always get the correct checksum (and a matching tarball), that is, the one matching gcc46/distinfo in FreeBSD Ports CVS. If you download directly from ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120608/gcc-4.6-20120608.tar.bz2 and put that into ports/distfiles, that should work? Alternatively, download repeatedly until it hits a different mirror? Gerald Now, call my paranoid but shouldn't he warn the mirror's operator ? Could be a bad transfer from the main site to the mirror , could be a hijacked source. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: lost ZFS pool
On 12 Jun 2012, at 20:17, Nenhum_de_Nos math...@eternamente.info wrote: hail, I write just to make sure its dead. I've lost the first disk on a ZFS pool (jbod). Now I can't mount it with only the second disk. The first disk clicks to death :( [root@optimus ~]# zpool status pool: pool state: UNAVAIL status: One or more devices could not be opened. There are insufficient replicas for the pool to continue functioning. action: Attach the missing device and online it using 'zpool online'. see: http://www.sun.com/msg/ZFS-8000-3C scrub: none requested config: NAME STATE READ WRITE CKSUM pool UNAVAIL 0 0 0 insufficient replicas label/zfs1 UNAVAIL 0 0 0 cannot open label/zfs2 ONLINE 0 0 I have a spare disk (blank), but even though I can't make it online again ... is there any hope I can read the files in that disk ? thanks, matheus Johan has the right of it, you're splitting data between your 2 devices a la raid0, this means both disks are required for the pool to function. Your data is gone and you're not recovering any of it. You will want to follow Johan's recommendation of using mirror (raid1), raidz (raid5) or even raidz2 (raid6) to ensure data integrity and availability. Note that using raid does *not* exempt you from running backups. As has been pointed out already (Jeremy Chadwick was that you ?), with large disks ( 1TB ) you encounter the risk of another disk in your raid array failing while you're rebuilding on the replacement drive, because of the high IO. Also, while I am a proponent of using the full disk for ZFS (as opposed to a slice), it is recommended to use slices and shave off roughly 100mb from the disk space available when creating your pool. This way, if an old disk fails and you replace it with one the same size but from another manufacturer (the size may vary a bit, imagine if it's 2mb smaller, you can't use it in your pool !) you won't face the problem.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Ports from a particular date in the past... Re: Why Are You NOT Using FreeBSD?
On 6 Jun 2012, at 23:10, grenville armitage garmit...@swin.edu.au wrote: On 06/07/2012 00:16, Chris Rees wrote: On 6 June 2012 14:12, Ericherichfreebsdl...@ovitrap.com wrote: [..] is my English really this bad? From the handbook: '. In particular, use only tag=. for the ports-* collections.' Your English is fine, but being told to use tag=. != tag=. is the only tag that exists. Another data point: In Erich's defense, I'd say his interpretation is quite understandable. ...use only tag=. for the ports-* collections also left me with the distinct impression (some many moons in the past) that there are no other meaningful (or safe) tags when csup'ing the Ports tree. In 12 years of using FreeBSD I've never really sought out Erich's use case (viz. roll back /usr/ports to some past known-good version), I just assumed it wasn't possible. So this thread has taught at least one person (me) a new thing -- I never fully grokked that adding date= to the supfile could achieve this desired result when csup'ing the Ports tree. Now I know, and I've changed the Subject line of this email in the hope it helps some future soul googling for the answer. cheers, gja Actually does , flagging post for future reading. Thanks guys. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
PFsync firewall states updates (was: Re: Why Are You Using FreeBSD?)
On 5/31/12 9:51 PM, Nick Gustas wrote: On 5/31/2012 12:52 PM, Damien Fleuriot wrote: On 5/31/12 6:37 PM, Nikos Vassiliadis wrote: On 5/31/2012 5:41 PM, Damien Fleuriot wrote: Furthermore, when upgrading the CARP Master firewall, we need to plan with the Project Manager a failover to the CARP Backup firewall. Yes, I know about pfsync, yes, we use it, no, it doesn't *instantly* sync sessions for PF. A bit offtopic on this thread, but isn't pfsync designed to do just that? instantly? With instantly I really mean: Communicate every change to the stable table to the other firewall in order to let the stateful connections survive a firewall failover. Obviously, some packets will be lost, but TCP connections should survive, right? I am not arguing, I ask. Nikos Updates aren't instantaneous, they're sent in bundles. This means that when you failover, you lose the connections that have completed a SYN/SYNACK/ACK sequence on your main firewall but which aren't synched on your backup. These connections will continue with the peer sending regular non-syn packets, which your backup-now-master PF will drop. On topic, if anyone has an awesome idea around this, I'm all ears, this exact topic is causing us some level of discomfort at work, when we need to swap firewalls for updates. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org I don't see this option on FreeBSD 9, but on OpenBSD pfsync has a defer flag that would appear to address your issue. The options are as follows: defer Defer transmission of the first packet in a state until a peer has acknowledged that the associated state has been inserted. See pfsync(4) for more information. -defer Do not defer the first packet in a state. This is the default. From pfsync(4) The pfsync interface will attempt to collapse multiple state updates into a single packet where possible. The maximum number of times a single state can be updated before a pfsync packet will be sent out is con- trolled by the maxupd parameter to ifconfig (see ifconfig(8) and the ex- ample below for more details). The sending out of a pfsync packet will be delayed by a maximum of one second. Where more than one firewall might actively handle packets, e.g. with certain ospfd(8), bgpd(8) or carp(4) configurations, it is beneficial to defer transmission of the initial packet of a connection. The pfsync state insert message is sent immediately; the packet is queued until ei- ther this message is acknowledged by another system, or a timeout has ex- pired. This behaviour is enabled with the defer parameter to ifconfig(8). I'm sure this could be ported over. -Nick This mimics the behavior of some manufacturers like Juniper and is *definitely* the kind of option we're looking for. While I lack the skills to port this, I'm definitely available for testing. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 5/31/12 8:13 PM, Matthew Seaman wrote: On 31/05/2012 16:41, Damien Fleuriot wrote: You missed the bit about 3 reboots, while these don't take 15 mins each, they're still time consuming and disruptive. 1/ reboot after installing new kernel 2/ reboot after installing new world 3/ reboot after rebuilding ports If you rebuilt the ports first, then you'ld only have two reboots. Also, while the cautious approach detailed in /usr/src/UPDATING is never wrong, much of the time you can do the upgrade perfectly well by installing world+kernel together and just rebooting once. Obviously this is not a good idea if your machines are in a datacenter many miles away and you don't have console-equivalent access or if you're upgrading over a large delta in versions, or you're making major changes to the kernel config. This sort of operation is something that ZFS boot environment support (recently committed to HEAD, due for MFC within the month) makes much, much safer and easier to deal with. You don't need to do a separate reboot to test the kernel as you've still got an entire kernel+world in the previous BE to fall back on. Cheers, Matthew The reason I rebuild the ports last is because, unless I'm wrong, any port that's statically linked to a system library would be linked to the old library from the old world. We've got very high HA constraints on these machines and I really prefer doing this the cautious way. Hell, on the first reboot I actually test the new kernel with nextboot -k , even when doing 8.2-RELEASE - 8-STABLE upgrades... Regarding the ZFS boot thingy, I'm not comfortable enough with it to push it in production, so we're still using UFS here. Sure looks interesting though. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 6/1/12 8:54 AM, Daniel Kalchev wrote: On 31.05.12 18:41, Damien Fleuriot wrote: You missed the bit about 3 reboots, while these don't take 15 mins each, they're still time consuming and disruptive. 1/ reboot after installing new kernel 2/ reboot after installing new world 3/ reboot after rebuilding ports About the only time I ever do that is when moving from very distant versions, like from 6.4 to 9.0... Upgrading from say, 8-stable from year ago, to today's 8-stable usually requires just one reboot: rebuild world, kernel, reinstall kernel, world, update configuration files, rebuild ports, reboot. There are many cases where I do rebuild/reinstall kernel and world but do not reboot for one reason or other. Cases, where the kernel is incompatible with userspace are extremely rare and typically documented. So yes, for example during port rebuild there might be glitches with services. You are better to shut down these services that will be affected, like web server. (Although usually say, apache would load all modules at startup time and replacing them under its feet will only be noticed after it is restarted). Most of the time however is spent just compiling... and unless your server is really underpowered or overloaded it does not impact anything. This again, is especially true for the OS. I wish ports could be rebuilt and reinstalled on a single step like FreeBSD. In any case, if you have 'server farms', or like you said firewalls with CARP etc, you can usually shut down any of the members for as long as necessary and not impact any services. If you rebuild things on 'central' server, the downtime will be indeed minimal. Daniel Yup I've been considering using a central server to hold /usr/src and /usr/obj for some time, would save me quite some time... I'll try to put something of the sort in place sometime this summer, the less painful the updates, the more likely we are to actually publish them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 5/30/12 8:20 PM, David Chisnall wrote: Hi Everyone, This is off-topic, so please feel free to disregard it, but I'm sending it to this list in the hope that it will reach a largish number of users. I am currently looking at updating some of our advocacy material (which advertises exciting new features like SMP support), and before I do I'd like to get a better feel for why the rest of you are using FreeBSD. If you had to list the three things you most like about FreeBSD, which would you pick? Are they the same as when you first started using it? David We're using FreeBSD here only for firewall boxes. Reasons for using FBSD for firewalls: - CARP - relayd - PF - pfsync Reasons I can't get management to use FBSD for regular servers (web, haproxy, db...): - hard to use - update process is hard, time-consuming and annoying (as opposed to debian's for example) A regular debian update is 5 minutes + reboot A regular FBSD update is about 1.5 hour + 3 reboots (after installkernel, installworld, rebuild of ports) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 31 May 2012, at 12:21, Lars Engels lars.eng...@0x20.net wrote: On Thu, May 31, 2012 at 12:06:55PM +0200, Damien Fleuriot wrote: On 5/30/12 8:20 PM, David Chisnall wrote: Hi Everyone, This is off-topic, so please feel free to disregard it, but I'm sending it to this list in the hope that it will reach a largish number of users. I am currently looking at updating some of our advocacy material (which advertises exciting new features like SMP support), and before I do I'd like to get a better feel for why the rest of you are using FreeBSD. If you had to list the three things you most like about FreeBSD, which would you pick? Are they the same as when you first started using it? David We're using FreeBSD here only for firewall boxes. Reasons for using FBSD for firewalls: - CARP - relayd - PF - pfsync Reasons I can't get management to use FBSD for regular servers (web, haproxy, db...): - hard to use - update process is hard, time-consuming and annoying (as opposed to debian's for example) A regular debian update is 5 minutes + reboot A regular FBSD update is about 1.5 hour + 3 reboots (after installkernel, installworld, rebuild of ports) But how often do you need to As a matter of fact, too often, that's te problem. We have 800 servers and I can't argue that debian's update process is much simpler and faster. There is also the performance aspect. We get better performance on Haproxy and PGsql on Debian than on bsd.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 5/31/12 12:32 PM, Holger Kipp wrote: Hi, Am 31.05.2012 um 12:24 schrieb Lars Engels lars.eng...@0x20.net: On Thu, May 31, 2012 at 12:06:55PM +0200, Damien Fleuriot wrote: On 5/30/12 8:20 PM, David Chisnall wrote: Hi Everyone, This is off-topic, so please feel free to disregard it, but I'm sending it to this list in the hope that it will reach a largish number of users. I am currently looking at updating some of our advocacy material (which advertises exciting new features like SMP support), and before I do I'd like to get a better feel for why the rest of you are using FreeBSD. If you had to list the three things you most like about FreeBSD, which would you pick? Are they the same as when you first started using it? David We're using FreeBSD here only for firewall boxes. Reasons for using FBSD for firewalls: - CARP - relayd - PF - pfsync Reasons I can't get management to use FBSD for regular servers (web, haproxy, db...): - hard to use - update process is hard, time-consuming and annoying (as opposed to debian's for example) A regular debian update is 5 minutes + reboot A regular FBSD update is about 1.5 hour + 3 reboots (after installkernel, installworld, rebuild of ports) But how often do you need to update? That reminds me - there is still a 2.2.8 system up and running that needs to be replaced ;-) For a server farm, one can use a central server who provides all packages that need to be upgraded, so it is usually only one system that needs a longer time. All others just mount the directories and install/upgrade using compiled world and /usr/ports/packages/All :-) Nice and easy. Best regards, Holger Your idea has merit and we've already considered it. However, these boxes are on different VLANs for security and confinement reasons and I loathe putting them on a shared VLAN just for this purpose. Besides, if the main server were to crash, we'd run into problems. We don't wish to introduce a SPOF. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 5/31/12 1:20 PM, Claus Guttesen wrote: A regular debian update is 5 minutes + reboot A regular FBSD update is about 1.5 hour + 3 reboots (after installkernel, installworld, rebuild of ports) But how often do you need to As a matter of fact, too often, that's te problem. We have 800 servers and I can't argue that debian's update process is much simpler and faster. Take a look at freebsd-update: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/updating-upgrading-freebsdupdate.html. This tracks release. As I just replied to an off-list mail, we can't use binary upgrades because: 1/ we use custom kernels with a lot of the stuff stripped 2/ we pass custom options to ports, which excludes pre-compiled packages 3/ we don't track release, I'm trying to move our boxes away from it so we can get faster patches, we track 8-STABLE on most boxes ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
IPv6 and CARP crashes boxes
Hey list, The thread about Why Are You Using FreeBSD, listing the pros and cons of FBSD, has brought back a topic to mind. Recently (read, 3 months ago) I was experimenting with IPv6 and CARP on 8.x boxes and that crashed them both. I posted a thread on -net and, sadly, never got a single reply. Has anyone else run into problems when using IPv6 + CARP ? I plan to hold a presentation at work on IP6 and why we should start using it, however I cannot promote the use of IP6 without redundancy between firewalls like we currently do with CARP + pfsync. I can, of course, post additional information as required. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 5/31/12 4:01 PM, Jim Ohlstein wrote: To add others, in no particular order: Ease of upgrade. While some have noted that binary upgrades are easier on Debian, it's far and away superior, IMMHO, to have a locally compiled system. Many Linux distros have no upgrade path short of a wipe and re-install. Far superior, check, FAR MORE TIME CONSUMING, check as well ! Also, I don't get your linux distros have no upgrade path short of a full reinstall bit ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 5/31/12 4:30 PM, Adam Strohl wrote: On 5/31/2012 21:22, Damien Fleuriot wrote: On 5/31/12 4:01 PM, Jim Ohlstein wrote: To add others, in no particular order: Ease of upgrade. While some have noted that binary upgrades are easier on Debian, it's far and away superior, IMMHO, to have a locally compiled system. Many Linux distros have no upgrade path short of a wipe and re-install. Far superior, check, FAR MORE TIME CONSUMING, check as well ! This brings up another point: Repair is always possible with FreeBSD. You can back out all packages or types of packages easily (and re-compile or reinstall them if needed). You can recompile/reinstall the OS if needed (somewhere else too and copy it over). Or just copy pieces from a live cd or restore tarball. And it's pretty straightforward to do even for a non-admin person. You can even restore over a live running system with tar, which I do occasionally when cloning machines or restoring them with dump/restore. Very slick. Regarding recovering from blunders, and dump/restore for restoration or even cloning purposes, I also use them and I can advocate the efficiency and usefulness. Regarding packages, I've never really explored it, would you detail a bit ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 5/31/12 5:13 PM, Jim Ohlstein wrote: On 5/31/12 10:22 AM, Damien Fleuriot wrote: On 5/31/12 4:01 PM, Jim Ohlstein wrote: To add others, in no particular order: Ease of upgrade. While some have noted that binary upgrades are easier on Debian, it's far and away superior, IMMHO, to have a locally compiled system. Many Linux distros have no upgrade path short of a wipe and re-install. Far superior, check, FAR MORE TIME CONSUMING, check as well ! No need to yell. Good things take time. That's life. The thing that takes the most time is building world. My boxes stay online during that time, and I am usually doing other things, so who cares if it takes an hour or so? I only take the system offline after I've installed the new kernel. I boot into single user mode, install world and reboot. Cleaning up configuration files takes a few minutes, then I'm good to go. While I do rebuild all ports, I have only had *one* occasion where a binary built on an older system croaked on a new kernel. I have about 500 ports installed so maybe that's not that many. I upgrade my systems once or twice a year. It's not really a lot of time for me. We upgrade them when vulnerabilities and bug fixes show up, which is certainly more than 2/year. Linux distros all certainly require a reboot for a new kernel and some likely require editing of config files. So where is the far more time consuming? In the compiling? Sorry, but I'm not one to sit and watch the lines go by on the terminal. I have better things to do and I do them. If the compilation hits a snag I'd find out why, fix it, and run it again. You missed the bit about 3 reboots, while these don't take 15 mins each, they're still time consuming and disruptive. 1/ reboot after installing new kernel 2/ reboot after installing new world 3/ reboot after rebuilding ports Either you don't have that many fbsd boxes to manage, or you're doing it much better than we are. Let me lay it out for you: We use these boxes as firewalls for our company's projects. Between dev, pre-production, QA and production environments we have roughly 40 of these. They rarely share the same installed ports, nor the same hardware and thus kernel files. Furthermore, when upgrading the CARP Master firewall, we need to plan with the Project Manager a failover to the CARP Backup firewall. Yes, I know about pfsync, yes, we use it, no, it doesn't *instantly* sync sessions for PF. This, is actually quite a pain as well because the Project Managers are loath to swap between firewalls, and we need to do it nightly. These factors + source upgrade = major pain ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Why Are You Using FreeBSD?
On 5/31/12 6:37 PM, Nikos Vassiliadis wrote: On 5/31/2012 5:41 PM, Damien Fleuriot wrote: Furthermore, when upgrading the CARP Master firewall, we need to plan with the Project Manager a failover to the CARP Backup firewall. Yes, I know about pfsync, yes, we use it, no, it doesn't *instantly* sync sessions for PF. A bit offtopic on this thread, but isn't pfsync designed to do just that? instantly? With instantly I really mean: Communicate every change to the stable table to the other firewall in order to let the stateful connections survive a firewall failover. Obviously, some packets will be lost, but TCP connections should survive, right? I am not arguing, I ask. Nikos Updates aren't instantaneous, they're sent in bundles. This means that when you failover, you lose the connections that have completed a SYN/SYNACK/ACK sequence on your main firewall but which aren't synched on your backup. These connections will continue with the peer sending regular non-syn packets, which your backup-now-master PF will drop. On topic, if anyone has an awesome idea around this, I'm all ears, this exact topic is causing us some level of discomfort at work, when we need to swap firewalls for updates. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: IPv6 and CARP crashes boxes
On 31 May 2012, at 22:31, Adrian Chadd adr...@freebsd.org wrote: On 31 May 2012 06:42, Damien Fleuriot m...@my.gd wrote: Hey list, The thread about Why Are You Using FreeBSD, listing the pros and cons of FBSD, has brought back a topic to mind. Recently (read, 3 months ago) I was experimenting with IPv6 and CARP on 8.x boxes and that crashed them both. I posted a thread on -net and, sadly, never got a single reply. Did you file a PR? Chances are bz (IPv6 maintainer) has just been very busy. :-) Adrian I was actually trying to get some feedback on -net and see if anyone had encountered the problem before filling a PR. I guess I'll reproduce the problem, fill a PR, then post here so we can discuss it and make things move forward. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: /var getting full
Type: sync Then: df -h Then: cd /var du -hd 1 Post results. On 4/27/12 5:16 PM, Efraín Déctor wrote: I forgot this: /dev/da0s1d 11G9.9G457M96%/var From: Efraín Déctor Sent: Friday, April 27, 2012 10:14 AM To: freebsd-stable@freebsd.org Subject: /var getting full Hello. I have a server using FreeBSD 8.2, and recently I’ve noticed that /var is getting full But du –hs /var shows me this: 14M/var/ How Can I know what is using var to free space? Thank you. OS info: FreeBSD edh.edh 8.2-RELEASE-p3 FreeBSD 8.2-RELEASE-p3 #0: Tue Sep 27 18:45:57 UTC 2011 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: RELENG_8 still identifies itself as 8.3-PRERELEASE
On 4/23/12 5:01 AM, Adrian Wontroba wrote: On Sun, Apr 22, 2012 at 10:39:44PM +, Bjoern A. Zeeb wrote: On 22. Apr 2012, at 21:59 , Adrian Wontroba wrote: A RELENG_8 system built this morning still identifies itself as 8.3-PRERELEASE. Any chance of this becoming 8.3-STABLE soon? While this is entirely cosmetic, it does cause me issues at $JOB. Fixed. Thanks! Thanks also for the suggestions from others. Would like to +1 this as I've had the same issue at work. Cheers. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
PF - pf not loading non-persist tables from main ruleset on 8.3-PRERELEASE
Hello list, I installed a box recently and updated it to 8.3-PRERELEASE on 2012/04/11 I'm experiencing this extremely weird behavior where PF refuses to load standard and const table definitions from the main ruleset. - persist tables load just fine - normal and const tables inside anchors load just fine Does anyone else have the same problem ? I'll try to update the kernel again, you never know. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: New LSI mps driver for 9.0
On 3/8/12 6:33 PM, Desai, Kashyap wrote: -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Freddie Cash Sent: Thursday, March 08, 2012 10:00 PM To: Johan Hendriks Cc: freebsd-stable Subject: Re: New LSI mps driver for 9.0 On Thu, Mar 8, 2012 at 8:17 AM, Johan Hendriks joh.hendr...@gmail.com wrote: Is it possible to get a 'official' patch for the latest LSI mps driver for 9.0 RELEASE. There are patches floating around for mpslsi(4) for 9.0. And, if you upgrade to stable/9, mps(4) *is* the official driver from LSI. I know it is bad timing. FreeBSD-9 mps very old driver. You should migrate to FreeBSD-9-stable and if you want just pick mps driver from there and port it to FreeBSD-9-RELEASE. ~ Kashyap Kashyap, do you see any problem with taking the mps(4) driver from stable/9 and compiling/installing it on stable/8 ? If you can't see a huge problem forthcoming, I'd be willing to try that and validate it works as advertised. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FreeBSD9 and the sheer number of problem reports
On 2/26/12 10:30 AM, Erich Dollansky wrote: No matter what effort you put into testing, you can never achieve the robustness of an older release. I still have 7.4 running on one. This can stay until next year. So, why do you want to run the latest release on an important machine? You can, but you are not in a position to complain then. Erich Do you not see this as a *huge* problem ? This means even fewer testers, again ! This weekend I replaced a server, moved it from 6.4-STABLE to 8.3-PRERELEASE. Hell, as far as I'm concerned it could have stayed on 6.4-STABLE to be honest, but I needed to replace the hardware which was getting old. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: random problem with 8.3 from yesterday
On 26 Feb 2012, at 05:06, Erich Dollansky erichfreebsdl...@ovitrap.com wrote: Hi, On Sunday 26 February 2012 00:55:46 Kevin Oberman wrote: I thought he was creating a monolithic device...what was called dangerously dedicated. No slices at all. Not only are DD volumes yes, I remember this term. And Windows machines get confused but they do not damage the media. mountable, they are bootable. It's been years since I created a DD disk as the slight space savings are irrelevant on modern hundreds of gigabyte disks, so I may have forgotten how it works. It might still make sense on a small thumb drive, bootable or not. Never break a winning team. The script doing the job works since a long time. This is the simple reason behind. Ok so since nobody mentioned it, does the problem happen for ALL your media handled in the same fashion, or just the one drive ? What I'm saying is don't blame the software so readily when it might be hardware. Get a SMART report on your disk. Also try with another media.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FreeBSD9 and the sheer number of problem reports
Hello list, This is NOT a troll. This is NOT a flame. Do NOT hijack this thread to troll/flame. I'm writing this in light of the *many* problem reports I see on the lists with 9.0-RELEASE. I'm getting extremely worried here. Short introduction in order: See, we use FreeBSD at work for our firewall boxes, running: - PF + CARP + PFsync - nagios-nrpe - munin-node - bacula client and either - nginx and/or haproxy - relayd These boxes serve as frontend firewalls for all our projects/products, including a few high traffic ones. For example our most traffic intense project has 4 firewalls, 2 each on 2 different datacenters, sharing 4 CARP IPs with automagic failover. These firewalls total ~200mb/s , serving only minifi'ed javascript pages. Now, I find the number of problem reports regarding 9.0-RELEASE alarming and I'm growing more and more fearful towards it. In the current state of things, I have *absolutely* no wish to run it in production :( I'd love to hear feedback. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CARP carpdev
On 2/14/12 11:04 PM, Hugo Silva wrote: On 02/14/12 17:33, Freddie Cash wrote: On Tue, Feb 14, 2012 at 8:56 AM, Hugo Silvah...@barafranca.com wrote: Looks like there's been conversations about porting this to FreeBSD since at least 2007. Are there any plans to have ifconfig carpdev available in 9.0-STABLE? CARP support has been redone in 10-CURRENT, removing the whole carp0 pseudo-interface support, and just enabling the CARP protocol on the existing network interfaces. This includes the equivalent of carpdev support. Search the -current archives for more information, CFT, and so on. I don't recall seeing anything about specific plans to MFC to stable/9, but could be mis-remembering things. http://svnweb.freebsd.org/base?view=revisionrevision=228571 The single IP limitation may be a problem in some locations.. Did not find anything about a possible MFC either. glebius@ is cc'd, perhaps he can add something, but based on http://svn.freebsd.org/base/stable/9/UPDATING, I don't think it's been MFCd (there's a primer for the new carp in current's UPDATING)\ I think what Gleb meant by It also allows to run a single redundant IP per interface is that, like in OpenBSD, you won't need to assign a physical IP address in the same subnet as the CARP IP you want to use, on your system. LEGACY: - 1 physical IP in subnet XY on a physical interface - 1 virtual IP in subnet XY on a carp interface HEAD: - 1 virtual IP in subnet XY on a physical interface Although, you're still allowed to assign a physical IP to suit your needs. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mps module compilation issue on FreeBSD-9 amd64
On 1/30/12 10:15 AM, Desai, Kashyap wrote: Hi, I am seeing some uncommon problem while doing compilation of mps driver (this is a latest driver from LSI). Here are the steps I followed. CASE-1 1. remove mps directory from sys/dev and sys/module and overwrite those two directories with my latest code. 2. go to sys/module/mps and run make. [Things works fine.] CASE-2. 1. remove mps directory from sys/dev and sys/module and overwrite those two directories with my latest code. 2. go to main directory ( In my case it is /usr/trees/9.0.0) 3. Run below command make -j8 buildkernel KERNCONF=GENERIC MODULES_OVERRIDE=mps TARGET_ARCH=amd64 SYSDIR=/usr/trees/9.0.0/sys -DNO_CLEAN -DNO_KERNELCONFIG -DNO_KERNELCLEAN -DNO_KERNELDEPEND Why are you multithreading your kernel build ? I might be mistaken but I've always read you're *NOT* supposed to do that, only with the world ! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mps module compilation issue on FreeBSD-9 amd64
I'm glad you've got this sorted. Out of curiosity, what does the new version bring ? On 1/30/12 11:29 AM, Desai, Kashyap wrote: After applying below patch on my tree, things are working fine.. *** src/sys/conf/files.orig --- src/sys/conf/files *** *** 1469,1476 --- 1469,1479 dev/mmc/mmcsd.c optional mmcsd dev/mn/if_mn.c optional mn pci dev/mps/mps.c optional mps + dev/mps/mps_config.coptional mps + dev/mps/mps_mapping.c optional mps dev/mps/mps_pci.c optional mps pci dev/mps/mps_sas.c optional mps + dev/mps/mps_sas_lsi.c optional mps dev/mps/mps_table.c optional mps dev/mps/mps_user.c optional mps dev/mpt/mpt.c optional mp In LSI's new driver we have mps_config.c, mps_mapping.c and mps_sas_lsi.c new files added. This needs to be updated in sys/conf/files _But_ still unresolved question is why it worked fine for i386 build and failed only for amd64. Anyways, Thanks for helping me out. I am happy to continue with above mentioned fix. ` Kashyap -Original Message- From: Desai, Kashyap Sent: Monday, January 30, 2012 3:30 PM To: 'Damien Fleuriot'; freebsd-stable@freebsd.org Subject: RE: mps module compilation issue on FreeBSD-9 amd64 -Original Message- From: owner-freebsd-sta...@freebsd.org [mailto:owner-freebsd- sta...@freebsd.org] On Behalf Of Damien Fleuriot Sent: Monday, January 30, 2012 3:18 PM To: freebsd-stable@freebsd.org Subject: Re: mps module compilation issue on FreeBSD-9 amd64 On 1/30/12 10:15 AM, Desai, Kashyap wrote: Hi, I am seeing some uncommon problem while doing compilation of mps driver (this is a latest driver from LSI). Here are the steps I followed. CASE-1 1. remove mps directory from sys/dev and sys/module and overwrite those two directories with my latest code. 2. go to sys/module/mps and run make. [Things works fine.] CASE-2. 1. remove mps directory from sys/dev and sys/module and overwrite those two directories with my latest code. 2. go to main directory ( In my case it is /usr/trees/9.0.0) 3. Run below command make -j8 buildkernel KERNCONF=GENERIC MODULES_OVERRIDE=mps TARGET_ARCH=amd64 SYSDIR=/usr/trees/9.0.0/sys -DNO_CLEAN - DNO_KERNELCONFIG -DNO_KERNELCLEAN -DNO_KERNELDEPEND Why are you multithreading your kernel build ? I might be mistaken but I've always read you're *NOT* supposed to do that, only with the world ! I have also tried with -j1. I observe post objcopy .. why there is linking kernel.debug steps .? This step is only seen for amd64 compilation. For i386, it finished immediate after objcopy prompt. --- objcopy --only-keep-debug mpslsi.ko.debug mpslsi.ko.symbols objcopy --strip-debug --add-gnu-debuglink=mpslsi.ko.symbols mpslsi.ko.debug mpslsi.ko /usr/local/bin/svnversion cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -g - Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing- prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer- sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show- option -nostdinc -I. -I/usr/trees/9.0.0/sys - I/usr/trees/9.0.0/sys/contrib/altq -D_KERNEL - DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline- limit=8000 --param inline-unit-growth=100 --param large-function- growth=1000 -fno-omit-frame-pointer -mno-sse -mcmodel=kernel -mno-red- zone -mno-mmx -msoft-float -fno-asynchronous-unwind-tables - ffreestanding -fstack-protector -Werror vers.c linking kernel.debug --- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable- unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: stuck /etc/rc autoboot processes
On 12/27/11 10:22 PM, Jeremy Chadwick wrote: On Tue, Dec 27, 2011 at 07:46:52PM +0100, Damien Fleuriot wrote: Hello list, Yesterday and today, I've been busy either patching boxes for the BIND advisory that we received on the 23rd (when they were running 8.1 or 8.2-RELEASE), or upgrading them (when running 8.0-RELEASE). Today I've come across 2 boxes running 8.2-STABLE and of course, the BIND patch wouldn't apply correctly. I've decided to cvsup them to 8.2-RELEASE and upgrade them to it. Why cvsup and not csup? You're correct, and I indeed used csup from the base system. Secondly, and more importantly, when upgrading to a different tag (e.g. you were using RELENG_8_0 before, moving to RELENG_8 or RELENG_8_2 -- you don't really explain in a coherent way what you did, you've mentioned 4 different FreeBSD versions above :-) ), I tend to do the following: Indded I've mentionned quite a few versions, because I had to patch and/or upgrade many of them over the last few days. They all went well, because most machines either didn't need upgrading (only BIND's patch), or were running 8.2-PRERELEASE or 8.0-RELEASE so I could upgrade them just fine. /usr/src/UPDATING didn't yield any warning so I went ahead. The upgrade that troubles me with these stuck processes is 8.2-STABLE down to 8.2-RELEASE-p5. For this as well, I have not seen anything in UPDATING. rm -fr /usr/obj/* rm -fr /var/db/sup/src-all rm -fr /usr/src/* csup ... That's a goood idea, I'll note that down. Are you sure about removing /usr/src/* ? I usually cd there and make update, without the Makefile it's gonna be tricky. The problem I've seen is that some source bits manage to figure out that they need to be updated to a different version based on the release tag in the cvsup/csup configuration file, but sometimes this doesn't work quite right and the underlying source files in /usr/src end up getting mix-matched between two versions. You may want to do this for ports as well, e.g.: rm -fr /var/db/sup/ports-all rm -fr /usr/ports/* csup ... It gets more tricky assuming during your original FreeBSD installation you chose to install src and ports. The below is the cvsup FAQ, but it applies to csup too. Read items 11, 12, and 13. http://www.cvsup.org/faq.html#caniadopt These boxes date back 1.5 year now and I don't remember how I installed them. I think it was sysinstall so yeah, sources + ports at the time. Welcome to why I never bother to install src or ports from CD/DVD, I simply use csup once the system is up. And for changing tags/releases, I do what's described above. I've gone through the following steps: - make buildworld - make buildkernel - make installkernel - nextboot -k my new kernel, to ensure it worked fine - rebooted again with the new kernel, this time correctly installed as /boot/kernel - installed the world - run mergemaster -FiPU - rebuild ports This doesn't look correct. The process you should be following is documented plainly in /usr/src/Makefile. You're missing some steps. Try doing what I recommended above, and following what's in /usr/src/Makefile, and then see if things improve. I'm reading through it now, the only steps I haven't run seem to be delete-old and delete-old-libs. I'll try that removing all /usr/src/ , /usr/obj/ , csuping again and redoing the steps including the removals. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: stuck /etc/rc autoboot processes
On 12/28/11 10:46 AM, Damien Fleuriot wrote: On 12/27/11 10:22 PM, Jeremy Chadwick wrote: On Tue, Dec 27, 2011 at 07:46:52PM +0100, Damien Fleuriot wrote: Hello list, Yesterday and today, I've been busy either patching boxes for the BIND advisory that we received on the 23rd (when they were running 8.1 or 8.2-RELEASE), or upgrading them (when running 8.0-RELEASE). Today I've come across 2 boxes running 8.2-STABLE and of course, the BIND patch wouldn't apply correctly. I've decided to cvsup them to 8.2-RELEASE and upgrade them to it. Why cvsup and not csup? You're correct, and I indeed used csup from the base system. Secondly, and more importantly, when upgrading to a different tag (e.g. you were using RELENG_8_0 before, moving to RELENG_8 or RELENG_8_2 -- you don't really explain in a coherent way what you did, you've mentioned 4 different FreeBSD versions above :-) ), I tend to do the following: Indded I've mentionned quite a few versions, because I had to patch and/or upgrade many of them over the last few days. They all went well, because most machines either didn't need upgrading (only BIND's patch), or were running 8.2-PRERELEASE or 8.0-RELEASE so I could upgrade them just fine. /usr/src/UPDATING didn't yield any warning so I went ahead. The upgrade that troubles me with these stuck processes is 8.2-STABLE down to 8.2-RELEASE-p5. For this as well, I have not seen anything in UPDATING. rm -fr /usr/obj/* rm -fr /var/db/sup/src-all rm -fr /usr/src/* csup ... That's a goood idea, I'll note that down. Are you sure about removing /usr/src/* ? I usually cd there and make update, without the Makefile it's gonna be tricky. The problem I've seen is that some source bits manage to figure out that they need to be updated to a different version based on the release tag in the cvsup/csup configuration file, but sometimes this doesn't work quite right and the underlying source files in /usr/src end up getting mix-matched between two versions. You may want to do this for ports as well, e.g.: rm -fr /var/db/sup/ports-all rm -fr /usr/ports/* csup ... It gets more tricky assuming during your original FreeBSD installation you chose to install src and ports. The below is the cvsup FAQ, but it applies to csup too. Read items 11, 12, and 13. http://www.cvsup.org/faq.html#caniadopt These boxes date back 1.5 year now and I don't remember how I installed them. I think it was sysinstall so yeah, sources + ports at the time. Welcome to why I never bother to install src or ports from CD/DVD, I simply use csup once the system is up. And for changing tags/releases, I do what's described above. I've gone through the following steps: - make buildworld - make buildkernel - make installkernel - nextboot -k my new kernel, to ensure it worked fine - rebooted again with the new kernel, this time correctly installed as /boot/kernel - installed the world - run mergemaster -FiPU - rebuild ports This doesn't look correct. The process you should be following is documented plainly in /usr/src/Makefile. You're missing some steps. Try doing what I recommended above, and following what's in /usr/src/Makefile, and then see if things improve. I'm reading through it now, the only steps I haven't run seem to be delete-old and delete-old-libs. I'll try that removing all /usr/src/ , /usr/obj/ , csuping again and redoing the steps including the removals. Ok so, for information. I've tracked this down to Local package initialization: stuck indefinitely at boot. I just logged on the machine's remote console and ^C 'd it, and that gave me a login prompt (although I could ssh just fine otherwise !) and cleared the autoboot processes. I'm now looking for the reason why this message was displayed and why it was stuck. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: stuck /etc/rc autoboot processes
On 12/28/11 11:50 AM, Sergey Kandaurov wrote: On 27 December 2011 22:46, Damien Fleuriot m...@my.gd wrote: Hello list, Yesterday and today, I've been busy either patching boxes for the BIND advisory that we received on the 23rd (when they were running 8.1 or 8.2-RELEASE), or upgrading them (when running 8.0-RELEASE). Today I've come across 2 boxes running 8.2-STABLE and of course, the BIND patch wouldn't apply correctly. I've decided to cvsup them to 8.2-RELEASE and upgrade them to it. I've gone through the following steps: - make buildworld - make buildkernel - make installkernel - nextboot -k my new kernel, to ensure it worked fine - rebooted again with the new kernel, this time correctly installed as /boot/kernel - installed the world - run mergemaster -FiPU - rebuild ports Now, I'm facing this odd situation where, just after booting, I get this on the 2 boxes: root 22 0.0 0.0 8256 1876 v0 Is+ 7:32PM 0:00.03 sh /etc/rc autoboot root 1250 0.0 0.0 18000 2576 v0 I+7:32PM 0:00.04 /usr/local/sbin/rsyslogd -a /var/run/log -a /var/named/var/run/log -i /var/run/syslog.pid -f /usr/local/etc/rsyslog.conf root 1790 0.0 0.0 8256 1952 v0 I+7:32PM 0:00.00 sh /etc/rc autoboot root 1793 0.0 0.0 8256 1952 v0 I+7:32PM 0:00.00 sh /etc/rc autoboot Does anybody have an idea why I get these stuck sh /etc/rc autoboot processes ? Any pointers as to where I should look ? Check if the box has a working resolving during boot. This is a main reason why it may stuck in /etc/rc phase. When on physical console, type ^T. Usually it will get you the name of offending process. You posted output from ps aux. It would be nice if you post ps auxl, so values of MWCHAN ps keyword will be also seen, which can add an additional debugging info. Find below the info: # ps aufx http://pastebin.com/iLy0Hs8s # ps aufxl http://pastebin.com/3meFWvRH # dmesg.boot http://pastebin.com/rFEsPfD5 Again, the box gets stuck at Local package initialization: from /etc/rc.d/localpkg I then run the following: # sh -x /etc/rc.d/localpkg A snip from the end of the script's output (stuck) yields: + logger 'localpkg: DEBUG: run_rc_command: doit: pkg_start ' + echo 'localpkg: DEBUG: run_rc_command: doit: pkg_start ' localpkg: DEBUG: run_rc_command: doit: pkg_start + eval 'pkg_start ' + pkg_start + local initdone + initdone='' + find_local_scripts_old + zlist='' + slist='' + [ -d /usr/local/etc/rc.d ] + grep '^# PROVIDE:' '/usr/local/etc/rc.d/[0-9]*.sh' + zlist=' /usr/local/etc/rc.d/[0-9]*.sh' + grep '^# PROVIDE:' /usr/local/etc/rc.d/relayd_check.sh + slist=' /usr/local/etc/rc.d/relayd_check.sh' + [ -z '' -a -f '/usr/local/etc/rc.d/[0-9]*.sh' ] + [ -x '/usr/local/etc/rc.d/[0-9]*.sh' ] + [ -f '/usr/local/etc/rc.d/[0-9]*.sh' -o -L '/usr/local/etc/rc.d/[0-9]*.sh' ] + [ -z '' -a -f /usr/local/etc/rc.d/relayd_check.sh ] + echo -n 'Local package initialization:' Local package initialization:+ initdone=yes + [ -x /usr/local/etc/rc.d/relayd_check.sh ] + set -T + trap 'exit 1' 2 + /usr/local/etc/rc.d/relayd_check.sh start relayd_check.sh is a custom script that I wrote to monitor relayd for crashes, log them to /var/log/ and restart the process. This script does *not* contain any PROVIDE / REQUIRE / KEYWORD initialization info and I'm beginning to think this may be the problem. I shall try further, thanks for all the pointers so far :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: stuck /etc/rc autoboot processes
On 12/28/11 1:38 PM, Jeremy Chadwick wrote: On Wed, Dec 28, 2011 at 11:45:37AM +0100, Damien Fleuriot wrote: On 12/28/11 10:46 AM, Damien Fleuriot wrote: On 12/27/11 10:22 PM, Jeremy Chadwick wrote: On Tue, Dec 27, 2011 at 07:46:52PM +0100, Damien Fleuriot wrote: The upgrade that troubles me with these stuck processes is 8.2-STABLE down to 8.2-RELEASE-p5. For this as well, I have not seen anything in UPDATING. rm -fr /usr/obj/* rm -fr /var/db/sup/src-all rm -fr /usr/src/* csup ... That's a goood idea, I'll note that down. Are you sure about removing /usr/src/* ? I realise you've found that it stalls on local package initialisation, but I wanted to answer this question: Yes, absolutely 100% sure about removing /usr/src/*. The reason is that the files within those directories contain CVS Id reference numbers that may not match what you're checking out via csup; meaning, there may be a conflict. It's best to remove /usr/src/* and /var/db/sup/src-all in this situation. Removing one but not the other can result in problems. Duly noted. I've gone through the following steps: - make buildworld - make buildkernel - make installkernel - nextboot -k my new kernel, to ensure it worked fine - rebooted again with the new kernel, this time correctly installed as /boot/kernel - installed the world - run mergemaster -FiPU - rebuild ports This doesn't look correct. The process you should be following is documented plainly in /usr/src/Makefile. You're missing some steps. Try doing what I recommended above, and following what's in /usr/src/Makefile, and then see if things improve. I'm reading through it now, the only steps I haven't run seem to be delete-old and delete-old-libs. It looks to me like you're missing the mergemaster -p stage, as well as booting into single-user to do the installation (unless of course by rebooted again with the new kernel and installed the world implied you booted into single-user). I've also forgotten to mention it but I did run mergemaster -p prior to rebooting on the new kernel. There were no notable diffs between our files, except mergemaster wanted to replace my old /etc/passwd , /etc/master.passwd and /etc/group , which is of course a no go. I'll try that removing all /usr/src/ , /usr/obj/ , csuping again and redoing the steps including the removals. I just logged on the machine's remote console and ^C 'd it, and that gave me a login prompt (although I could ssh just fine otherwise !) and cleared the autoboot processes. I'm now looking for the reason why this message was displayed and why it was stuck. Others have recommended rc_debug -- I agree with this. It may not shed entire light on what's going on (meaning we may end up knowing what command causes the problem but not what the command is doing internally). ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: stuck /etc/rc autoboot processes
On 12/28/11 12:37 PM, Sergey Kandaurov wrote: On 28 December 2011 15:11, Damien Fleuriot m...@my.gd wrote: On 12/28/11 11:50 AM, Sergey Kandaurov wrote: On 27 December 2011 22:46, Damien Fleuriot m...@my.gd wrote: Hello list, Yesterday and today, I've been busy either patching boxes for the BIND advisory that we received on the 23rd (when they were running 8.1 or 8.2-RELEASE), or upgrading them (when running 8.0-RELEASE). Today I've come across 2 boxes running 8.2-STABLE and of course, the BIND patch wouldn't apply correctly. I've decided to cvsup them to 8.2-RELEASE and upgrade them to it. I've gone through the following steps: - make buildworld - make buildkernel - make installkernel - nextboot -k my new kernel, to ensure it worked fine - rebooted again with the new kernel, this time correctly installed as /boot/kernel - installed the world - run mergemaster -FiPU - rebuild ports Now, I'm facing this odd situation where, just after booting, I get this on the 2 boxes: root 22 0.0 0.0 8256 1876 v0 Is+ 7:32PM 0:00.03 sh /etc/rc autoboot root 1250 0.0 0.0 18000 2576 v0 I+7:32PM 0:00.04 /usr/local/sbin/rsyslogd -a /var/run/log -a /var/named/var/run/log -i /var/run/syslog.pid -f /usr/local/etc/rsyslog.conf root 1790 0.0 0.0 8256 1952 v0 I+7:32PM 0:00.00 sh /etc/rc autoboot root 1793 0.0 0.0 8256 1952 v0 I+7:32PM 0:00.00 sh /etc/rc autoboot Does anybody have an idea why I get these stuck sh /etc/rc autoboot processes ? Any pointers as to where I should look ? Check if the box has a working resolving during boot. This is a main reason why it may stuck in /etc/rc phase. When on physical console, type ^T. Usually it will get you the name of offending process. You posted output from ps aux. It would be nice if you post ps auxl, so values of MWCHAN ps keyword will be also seen, which can add an additional debugging info. Find below the info: # ps aufx http://pastebin.com/iLy0Hs8s # ps aufxl http://pastebin.com/3meFWvRH # dmesg.boot http://pastebin.com/rFEsPfD5 Again, the box gets stuck at Local package initialization: from /etc/rc.d/localpkg I then run the following: # sh -x /etc/rc.d/localpkg A snip from the end of the script's output (stuck) yields: + logger 'localpkg: DEBUG: run_rc_command: doit: pkg_start ' + echo 'localpkg: DEBUG: run_rc_command: doit: pkg_start ' localpkg: DEBUG: run_rc_command: doit: pkg_start + eval 'pkg_start ' + pkg_start + local initdone + initdone='' + find_local_scripts_old + zlist='' + slist='' + [ -d /usr/local/etc/rc.d ] + grep '^# PROVIDE:' '/usr/local/etc/rc.d/[0-9]*.sh' + zlist=' /usr/local/etc/rc.d/[0-9]*.sh' + grep '^# PROVIDE:' /usr/local/etc/rc.d/relayd_check.sh + slist=' /usr/local/etc/rc.d/relayd_check.sh' + [ -z '' -a -f '/usr/local/etc/rc.d/[0-9]*.sh' ] + [ -x '/usr/local/etc/rc.d/[0-9]*.sh' ] + [ -f '/usr/local/etc/rc.d/[0-9]*.sh' -o -L '/usr/local/etc/rc.d/[0-9]*.sh' ] + [ -z '' -a -f /usr/local/etc/rc.d/relayd_check.sh ] + echo -n 'Local package initialization:' Local package initialization:+ initdone=yes + [ -x /usr/local/etc/rc.d/relayd_check.sh ] + set -T + trap 'exit 1' 2 + /usr/local/etc/rc.d/relayd_check.sh start relayd_check.sh is a custom script that I wrote to monitor relayd for crashes, log them to /var/log/ and restart the process. This script does *not* contain any PROVIDE / REQUIRE / KEYWORD initialization info and I'm beginning to think this may be the problem. I shall try further, thanks for all the pointers so far :) Yeah, just thought to point you out at sleeping relayd_check.sh, when I finished to read your mail :-). Ok, I was glad to help you. btw, rcorder(8) can help you to clarify a starting order for your process. Just use: rcorder /etc/rc.d/* /usr/local/etc/rc.d/* Well, that was definitely check_relayd.sh (which I have moved to check_relayd , to skip the .sh extension for consistency). I've also taken the opportunity to run yes | make delete-old from /usr/src I'm definitely not running make delete-old-libs though, I fear that might break things. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: [SOLVED] stuck /etc/rc autoboot processes
On 12/28/11 3:35 PM, Damien Fleuriot wrote: On 12/28/11 12:37 PM, Sergey Kandaurov wrote: On 28 December 2011 15:11, Damien Fleuriot m...@my.gd wrote: On 12/28/11 11:50 AM, Sergey Kandaurov wrote: On 27 December 2011 22:46, Damien Fleuriot m...@my.gd wrote: Hello list, Yesterday and today, I've been busy either patching boxes for the BIND advisory that we received on the 23rd (when they were running 8.1 or 8.2-RELEASE), or upgrading them (when running 8.0-RELEASE). Today I've come across 2 boxes running 8.2-STABLE and of course, the BIND patch wouldn't apply correctly. I've decided to cvsup them to 8.2-RELEASE and upgrade them to it. I've gone through the following steps: - make buildworld - make buildkernel - make installkernel - nextboot -k my new kernel, to ensure it worked fine - rebooted again with the new kernel, this time correctly installed as /boot/kernel - installed the world - run mergemaster -FiPU - rebuild ports Now, I'm facing this odd situation where, just after booting, I get this on the 2 boxes: root 22 0.0 0.0 8256 1876 v0 Is+ 7:32PM 0:00.03 sh /etc/rc autoboot root 1250 0.0 0.0 18000 2576 v0 I+7:32PM 0:00.04 /usr/local/sbin/rsyslogd -a /var/run/log -a /var/named/var/run/log -i /var/run/syslog.pid -f /usr/local/etc/rsyslog.conf root 1790 0.0 0.0 8256 1952 v0 I+7:32PM 0:00.00 sh /etc/rc autoboot root 1793 0.0 0.0 8256 1952 v0 I+7:32PM 0:00.00 sh /etc/rc autoboot Does anybody have an idea why I get these stuck sh /etc/rc autoboot processes ? Any pointers as to where I should look ? Check if the box has a working resolving during boot. This is a main reason why it may stuck in /etc/rc phase. When on physical console, type ^T. Usually it will get you the name of offending process. You posted output from ps aux. It would be nice if you post ps auxl, so values of MWCHAN ps keyword will be also seen, which can add an additional debugging info. Find below the info: # ps aufx http://pastebin.com/iLy0Hs8s # ps aufxl http://pastebin.com/3meFWvRH # dmesg.boot http://pastebin.com/rFEsPfD5 Again, the box gets stuck at Local package initialization: from /etc/rc.d/localpkg I then run the following: # sh -x /etc/rc.d/localpkg A snip from the end of the script's output (stuck) yields: + logger 'localpkg: DEBUG: run_rc_command: doit: pkg_start ' + echo 'localpkg: DEBUG: run_rc_command: doit: pkg_start ' localpkg: DEBUG: run_rc_command: doit: pkg_start + eval 'pkg_start ' + pkg_start + local initdone + initdone='' + find_local_scripts_old + zlist='' + slist='' + [ -d /usr/local/etc/rc.d ] + grep '^# PROVIDE:' '/usr/local/etc/rc.d/[0-9]*.sh' + zlist=' /usr/local/etc/rc.d/[0-9]*.sh' + grep '^# PROVIDE:' /usr/local/etc/rc.d/relayd_check.sh + slist=' /usr/local/etc/rc.d/relayd_check.sh' + [ -z '' -a -f '/usr/local/etc/rc.d/[0-9]*.sh' ] + [ -x '/usr/local/etc/rc.d/[0-9]*.sh' ] + [ -f '/usr/local/etc/rc.d/[0-9]*.sh' -o -L '/usr/local/etc/rc.d/[0-9]*.sh' ] + [ -z '' -a -f /usr/local/etc/rc.d/relayd_check.sh ] + echo -n 'Local package initialization:' Local package initialization:+ initdone=yes + [ -x /usr/local/etc/rc.d/relayd_check.sh ] + set -T + trap 'exit 1' 2 + /usr/local/etc/rc.d/relayd_check.sh start relayd_check.sh is a custom script that I wrote to monitor relayd for crashes, log them to /var/log/ and restart the process. This script does *not* contain any PROVIDE / REQUIRE / KEYWORD initialization info and I'm beginning to think this may be the problem. I shall try further, thanks for all the pointers so far :) Yeah, just thought to point you out at sleeping relayd_check.sh, when I finished to read your mail :-). Ok, I was glad to help you. btw, rcorder(8) can help you to clarify a starting order for your process. Just use: rcorder /etc/rc.d/* /usr/local/etc/rc.d/* Well, that was definitely check_relayd.sh (which I have moved to check_relayd , to skip the .sh extension for consistency). I've also taken the opportunity to run yes | make delete-old from /usr/src I'm definitely not running make delete-old-libs though, I fear that might break things. For anyone reading the archive, if you ever run into the same problem, aka a stuck sh /etc/rc autoboot or /etc/rc.d/localpkg, or a Initializing local packages: at boot. The problem was caused by a defective (meh) usermade script in /usr/local/etc/rc.d/ which missed rcorder tags, for example: # PROVIDE: relayd_check # REQUIRE: NETWORKING relayd # KEYWORD: shutdown Adding these solved the problem. Ty Sergey and Jeremy for your time. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
stuck /etc/rc autoboot processes
Hello list, Yesterday and today, I've been busy either patching boxes for the BIND advisory that we received on the 23rd (when they were running 8.1 or 8.2-RELEASE), or upgrading them (when running 8.0-RELEASE). Today I've come across 2 boxes running 8.2-STABLE and of course, the BIND patch wouldn't apply correctly. I've decided to cvsup them to 8.2-RELEASE and upgrade them to it. I've gone through the following steps: - make buildworld - make buildkernel - make installkernel - nextboot -k my new kernel, to ensure it worked fine - rebooted again with the new kernel, this time correctly installed as /boot/kernel - installed the world - run mergemaster -FiPU - rebuild ports Now, I'm facing this odd situation where, just after booting, I get this on the 2 boxes: root 22 0.0 0.0 8256 1876 v0 Is+ 7:32PM 0:00.03 sh /etc/rc autoboot root 1250 0.0 0.0 18000 2576 v0 I+7:32PM 0:00.04 /usr/local/sbin/rsyslogd -a /var/run/log -a /var/named/var/run/log -i /var/run/syslog.pid -f /usr/local/etc/rsyslog.conf root 1790 0.0 0.0 8256 1952 v0 I+7:32PM 0:00.00 sh /etc/rc autoboot root 1793 0.0 0.0 8256 1952 v0 I+7:32PM 0:00.00 sh /etc/rc autoboot Does anybody have an idea why I get these stuck sh /etc/rc autoboot processes ? Any pointers as to where I should look ? /var/run/dmesg.boot doesn't give much useful info. They're backup firewalls so I can run complementary tests on them as required. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FLAME - security advisories on the 23rd ? uncool idea is uncool
Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/11 5:39 PM, John Baldwin wrote: On Friday, December 23, 2011 11:07:56 am Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. From an e-mail sent to security@ from the security officer: quote Hi all, No, the Grinch didn't steal the FreeBSD security officer GPG key, and your eyes aren't deceiving you: We really did just send out 5 security advisories. The timing, to put it bluntly, sucks. We normally aim to release advisories on Wednesdays in order to maximize the number of system administrators who will be at work already; and we try very hard to avoid issuing advisories any time close to holidays for the same reason. The start of the Christmas weekend -- in some parts of the world it's already Saturday -- is absolutely not when we want to be releasing security advisories. Unfortunately my hand was forced: One of the issues (FreeBSD-SA-11:08.telnetd) is a remote root vulnerability which is being actively exploited in the wild; bugs really don't come any worse than this. On the positive side, most people have moved past telnet and on to SSH by now; but this is still not an issue we could postpone until a more convenient time. While I'm writing, a note to freebsd-update users: FreeBSD-SA-11:07.chroot has a rather messy fix involving adding a new interface to libc; this has the awkward side effect of causing the sizes of some symbols (aka. functions) in libc to change, resulting in cascading changes into many binaries. The long list of updated files is irritating, but isn't a sign that anything in freebsd-update went wrong. /quote At least they're aware the timing sucks completely and feel as sorry as us. Ty John. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
My point (which may or may not be valid) was that if the vulnerabilities remained *undisclosed*, they would have a much lower chance of being exploited. On 12/23/11 5:47 PM, Joe Holden wrote: So don't update until Monday? The outcome will be the same :) Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/11 5:50 PM, Stephen Montgomery-Smith wrote: On 12/23/2011 10:07 AM, Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? After receiving the fifth security advisory in a few moments, you will get a Christmas message from the Security Advisory team, which will both apologize and explain why these untimely advisories came today. http://lists.freebsd.org/pipermail/freebsd-security-notifications/2011-December/thread.html Indeed, just read the one John copied. Still sucks, but at least they're aware and apologetic about how the timing completely blows. Happy xmas. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: FLAME - security advisories on the 23rd ? uncool idea is uncool
On 12/23/11 5:54 PM, Bas Smeelen wrote: Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? What's the impact for your boxes? Only the BIND exploit concerns me, means that *potentially* servers for my projects might be unable to run DNS resolution anymore - prod problems. I don't think we'll be getting trouble though so I'm postponing the update until next week. I mean, couldn't this have waited and remained undisclosed until monday ? Best time to exploit is Christmas/holidays I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! updating 30 boxes right now Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. If you don't use telnet, ftpd, dns, pam, then it's not a big problem merry Christmas Disclaimer: http://www.ose.nl/email ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Goo lists to subscribe to hear quickly about vulns ? ( was: Re: FLAME - security advisories on the 23rd ? uncool idea is uncool)
On topic, where do you guys subscribe to know of these vulns ahead of their release on the ML ? I'm subscribed to the BIND ML but I don't recall seeing an advisory there ahead of today. On 12/23/11 6:03 PM, Shawn Webb wrote: Some people (like me) already knew about the vulnerabilities. And others are already exploiting some of these vulnerabilities. Thanks, Shawn Webb On Fri, Dec 23, 2011 at 9:50 AM, Damien Fleuriot m...@my.gd wrote: My point (which may or may not be valid) was that if the vulnerabilities remained *undisclosed*, they would have a much lower chance of being exploited. On 12/23/11 5:47 PM, Joe Holden wrote: So don't update until Monday? The outcome will be the same :) Damien Fleuriot wrote: Hey up list, Look, just a rant here. Who in *HELL* thought it would be a cool idea to release no less than FOUR security advisories today ? I mean, couldn't this have waited and remained undisclosed until monday ? I for one do *NOT* relish the idea of updating 50+ boxes this evening and tomorrow ! Not to mention a whole lot of merchants and banks have toggled IT Freeze a few weeks ago, to ensure xmas shopping doesn't get disturbed by production changes. Seriously, this is just irritating. /flame ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Two problems still present in RC3
On 12/9/11 11:10 AM, Johan Hendriks wrote: Brett Glass schreef: The interfaces SEEM to be configured correctly, but the messages -- which must be coming from scripts called by /etc/netstart -- are troubling. Same thing happens with lagg0 If i use this config, after a reboot all is fine ifconfig_em0=up ifconfig_em1=up cloned_interfaces=lagg0 ifconfig_lagg0=laggproto lacp laggport em0 laggport em1 192.168.100.1/24 I notice you're missing inet in your ifconfig_lagg0 line. Try this one instead: ifconfig_lagg0=laggproto lacp laggport em0 laggport em1 inet 192.168.100.1/24 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Two problems still present in RC3
On 12/9/11 10:13 AM, Brett Glass wrote: FreeBSD 9.0-RC3 is looking good, but I'm still encountering two problems. Firstly, when I try to configure VLANs in /etc/rc.conf, I'm getting errors. For example, if I use vlans_re0=1 2 ip_addrs_re0_1=192.168.0.1-4/16 ip_addrs_re0_2=10.0.0.0/24 to create two VLANs on the interface re0, I get error messages saying that create commands (presumably using ifconfig) have failed. The interfaces SEEM to be configured correctly, but the messages -- which must be coming from scripts called by /etc/netstart -- are troubling. Secondly, there's still some strangeness in the sc terminal emulation. When I run jove, the status line at the bottom of the screen isn't entirely in reverse video as it should be. Only parts of it are, and the highlighting changes -- seemingly at random -- as I work. Neither of these is likely to be a showstopper (so long as the first won't cause me networking problems I haven't observed yet), but both are probably worth looking into. I have never seen this way of configuring VLANs. Find below how I set them up on our firewalls, which works like a charm, but on 8.2. You may still want to give it a try on 9.0RC3, that might solve your problem. ### NETWORKING # Configure link aggregation ifconfig_bce0=up ifconfig_bce1=up ifconfig_em0=up ifconfig_lagg0=laggproto failover laggport bce0 laggport bce1 laggport em0 cloned_interfaces=lagg0 vlan14 vlan24 vlan34 carp14 carp24 carp34 # VLAN14 - WAN ifconfig_vlan14=inet [snip] vlan 14 vlandev lagg0 up # VLAN24 - DMZ ifconfig_vlan24=inet 192.168.24.252/24 vlan 24 vlandev lagg0 up # VLAN34 - LAN ifconfig_vlan34=inet 192.168.34.252/24 vlan 34 vlandev lagg0 up # VLAN 611 - VPNs ifconfig_vlan611=inet 10.106.11.252/24 vlan 611 vlandev lagg0 up ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Two problems still present in RC3
On 9 Dec 2011, at 18:30, Brett Glass br...@lariat.net wrote: At 03:10 AM 12/9/2011, Johan Hendriks wrote: After a /etc/netstart, i get the following: ifconfig: create: bad value. I get the create: bad value messages as well. What's more, if I change rc.conf to assign variables of the form ifconfig_*, such as ifconfig_re0_1=inet 192.168.0.1 ifconfig_re0_1_alias0=inet 192.168.0.2 ... instead of using an ip_addrs_* variable, I still get those messages. I have confirmed that if I run /etc/netstart after booting, I lose connectivity just as you do. I recognize the challenge of specifying the network configuration in a declaratory rather than a procedural environment, because there are so many contingencies and possible combinations of parameters. But there doesn't seem to be any combination of variables I can assign in rc.conf that doesn't cause errors when I try to create VLANs. --Brett Glass Try creating your VLANs as I described on my previous post and see if that helps ?___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: pf rdr rule question - corrected
On 10/31/11 12:04 AM, Gót András wrote: Dear All, I'd like to have the following ruleset, for pure-ftpd passive port range: (pasv and past mistyping corrected) --- ftp_pasv_start=X ftp_pasv_end=Y rdr on $netif inet proto tcp from any to $internalip port $ftp_pasv_start:$ftp_pasv_end - $internalip pass in quick on $netif proto tcp from any to $internalip port $ftp_pasv_start $ftp_pasv_end keep state flags S/SA pass in quick on $netif proto tcp from any to $internalip port $ftp_pasv_start:$ftp_pasv_end Both keep state and flags S/SA are default, you don't need to write them. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 8.1 xl + dual-speed Netgear hub = yoyo
On 10/21/11 5:00 PM, per...@pluto.rain.com wrote: I have an 8.1-RELEASE system with an xl on the mainboard: xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xdc80-0xdcff mem 0xf8fffc00-0xf8fffc7f irq 16 at device 4.0 on pci2 miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY PHY 24 on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:b0:d0:22:5a:14 xl0: [ITHREAD] It has been working properly while connected to an old 10-BaseT hub, but when I moved it to a (not as old) Netgear 10/100 dual-speed hub the link started to yo-yo: Pray tell, what's a dual-speed hub , marketing mumbo-jumbo ? If that's a hub that supports negotiation of different speeds (10 vs 100), then yes, I call that marketing mumbo-jumbo ;) Oct 21 07:16:00 fbsd81 kernel: xl0: link state changed to DOWN Oct 21 07:16:02 fbsd81 kernel: xl0: link state changed to UP Oct 21 07:16:12 fbsd81 kernel: xl0: link state changed to DOWN [snip] Both connections were using the same (short) Cat5 cable, I tried two different ports on the 10/100 hub, and other systems work OK on that 10/100 hub. How do I get this interface to operate properly at 100MB? You change your faulty cable and enjoy ;) It is totally possible that your cable be the cause, and that it can operate just fine at 10MB but not at 100. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: re unix browser problem
On 15 Oct 2011, at 14:24, kapral kap...@toya.net.pl wrote: Now i don't see any strange connections established but i had them b4 i wrote email i know my browsers connect to strange ip unfortunatly i didn't checked a port to whih was connected to but it was from high ports abowe 1024 on my local machine That is normal behaviour, your machine uses unprivileged ports for outgoing connections, which is a smart thing to do, as using ports 1024 requires root privileges. there was no stranege connections to google or other pages i visit nor the dns connection this ware connections established to adres i don't know and i didn't browse them from my browser sorry i wont put the output but i found it by lsof -i Regards Tomasz Marszal You would do well to heed Jeremy's advice, and read up on the links he's given you before questioning the validity of his answer ;) He often posts to the list and always goes the extra mile to back his claims with actual documentation or proof. Read the links he's provided, they will help you understand.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: nge(4), tl(4), wb(4) and rl(4) 8129 testers wanted [Re: Question about GPIO bitbang MII]
On 15 Oct 2011, at 22:56, Marius Strobl mar...@alchemy.franken.de wrote: Could owners of nge(4), tl(4), wb(4) and rl(4) driven hardware (as for rl(4) only 8129 need testing, 8139 don't) please give the following patch a try in order to ensure it doesn't break anything? for 9/head: http://people.freebsd.org/~marius/mii_bitbang.diff for 8: http://people.freebsd.org/~marius/mii_bitbang.diff8 Thanks, Marius While I don't have any box with this hardware, I'm thinking you might want to get a bit more specific about what you want tested... What do you think the patch might break ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.3 + kqueue + apache/php + DNS lookup problem
On 1 October 2011 03:18, Doug Barton do...@freebsd.org wrote: It's a php module doing a lookup for the hostname of the back-end mysql server. Are the delays always 3 seconds? Pretty much. If so, that almost sounds like a timeout of some kind. That was my first thought, but the answer always comes eventually. To answer Chuck's questions, no threading is involved, and it's not apache doing the lookups. Doug Check your bind/unbound logs to ensure the queries are actually successful on their first try. Is your DNS using forwarders ? views ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CARP interfaces and mastership issue
On 1 October 2011 11:04, johan Hendriks joh.hendr...@gmail.com wrote:
Op 29-09-11 16:49, Damien Fleuriot schreef:
Quick follow-up again.
This is the code for sys/netinet/ip_carp.c on FreeBSD 8.2, OpenBSD
3.8, OpenBSD 3.9 in function carp_setrun(struct carp_softc *sc,
sa_family_t af)
FREEBSD 8.2-PRERELEASE with init + preempt = auto MASTER bug
Function starts at line 1371.
---
switch (sc-sc_state) {
case INIT:
if (carp_opts[CARPCTL_PREEMPT] !carp_suppress_preempt)
{
carp_send_ad_locked(sc);
carp_send_arp(sc);
#ifdef INET6
carp_send_na(sc);
#endif /* INET6 */
CARP_LOG(%s: INIT - MASTER (preempting)\n,
SC2IFP(sc)-if_xname);
carp_set_state(sc, MASTER);
carp_setroute(sc, RTM_ADD);
} else {
CARP_LOG(%s: INIT - BACKUP\n,
SC2IFP(sc)-if_xname);
carp_set_state(sc, BACKUP);
carp_setroute(sc, RTM_DELETE);
carp_setrun(sc, 0);
}
break;
---
OPENBSD 3.8 with init + preempt = auto MASTER bug
Function starts at line 1293.
---
case INIT:
if (carp_opts[CARPCTL_PREEMPT] !carp_suppress_preempt)
{
carp_set_state(sc, MASTER);
carp_setroute(sc, RTM_ADD);
carp_send_ad(sc);
carp_send_arp(sc);
#ifdef INET6
carp_send_na(sc);
#endif /* INET6 */
} else {
carp_set_state(sc, BACKUP);
carp_setroute(sc, RTM_DELETE);
carp_setrun(sc, 0);
}
break;
---
OPENBSD 3.9 with bug fixed
Function starts at line 1348.
---
switch (sc-sc_state) {
case INIT:
carp_set_state(sc, BACKUP);
carp_setroute(sc, RTM_DELETE);
carp_setrun(sc, 0);
break;
---
It looks like the root cause is there.
I'll rebuild and test, keep you updated.
Find below my test results with the OpenBSD39 implementation which
forces an INIT - BACKUP transition regardless of preempt.
# sysctl net.inet.carp.preempt
net.inet.carp.preempt: 1
# sysctl net.inet.carp.suppress_preempt
net.inet.carp.suppress_preempt: 0
# ifconfig carp17
carp17: flags=8LOOPBACK metric 0 mtu 1500
inet 46.182.[snip] netmask 0x
inet 46.182.[snip] netmask 0x
inet 46.182.[snip] netmask 0x
inet 46.182.[snip] netmask 0x
inet 46.182.[snip] netmask 0x
carp: INIT vhid 117 advbase 1 advskew 200
# ifconfig carp17 up; ./check_carp17_status.sh
count: 0 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 1 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 2 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 3 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 4 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 5 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 6 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 7 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 8 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 9 carp: BACKUP vhid 117 advbase 1 advskew 200
count: 10 carp: BACKUP vhid 117 advbase 1 advskew 200
# dmesg
carp17: INIT - BACKUP
carp17: link state changed to DOWN
Looks like it works.
I'm afraid I cannot test actual preemption by shutting down a physical
interface on the MASTER, because they're actually used in production and
I've got users logged in to their VPN on pf1.
I see no reason this should break anything however, it only forces the
CARP interface to assume a BACKUP state right after INIT, as it normally
should, regardless of preemption.
I'm filling a PR + patch.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Do you have the PR number for me and the patch, i have the same problem and
like it to be fixed.
regards
Johan Hendriks
http://www.freebsd.org/cgi/query-pr.cgi?pr=161123
Here you go.
Please note I do not have extensive C programming experience.
I have simply removed the part that makes the CARP interface
immediately transition from INIT to MASTER when preemption is enabled,
and replaced it with an INIT-BACKUP transition like in OpenBSD3.9 in
which the bug is fixed.
I cannot guarantee the absence of side effects, although I couldn't
find any in my testing.
Also note that if you update your sources the patch will obviously be
gone, take care when
Re: CARP interfaces and mastership issue
On 9/15/11 11:07 AM, Damien FLEURIOT wrote: Hello list, TLDR: carp interface becomes MASTER for a split second after being created, even if another MASTER exists on the network with faster advertisements. Breaks connections. HOWTO prevent ? We've been experiencing this double mastership problem with CARP interfaces. Allow me to put some context here: 2 firewalls, PF1, PF2, each with 2 VLANs (for example, some have more) on a lagg device (link aggregation). These firewalls then share virtual IPs through CARP interfaces, let us assume the following: PF1: - vlan13 - vlan410 - carp13 (advskew 50) - carp410 (advskew 50) PF2: - vlan13 - vlan410 - carp13 (advskew 100) - carp410 (advskew 100) CARP preemption is turned on, so that if vlan13 should fail on PF1, PF2 would assume mastership on both CARP interfaces. Syscontrols below: net.inet.carp.allow: 1 net.inet.carp.preempt: 1 net.inet.carp.log: 1 net.inet.carp.arpbalance: 0 net.inet.carp.suppress_preempt: 0 The problem we have is, say for example we reboot PF2. When it comes back up, it will, even for a split second, assume CARP mastership for its interfaces, at the same time as PF1. This breaks existing sessions, openvpn tunnels and new client connections. While I acknowledge the home-made demons should be built to support tiny network outages, this doesn't solve our main problem. We have the same issue when destroying/creating said CARP interfaces. Recently we upgraded some switches' IOS version on our backup datacenter (which also has 2 PF boxes, sharing the CARP IPs with the 2 PFs on our production DC). To prevent anything nasty happening, we forbade production VLANs on the switches' uplink ports and only allowed management traffic to allow us to perform the upgrade. Things went smoothly but when we brought the production VLANs up again at layer 2 on the switches, when spanning-tree converged we had again a double MASTER problem. I understand I could have avoided it by destroying/recreating the CARP interfaces, but even in this case there is a split second during which both firewalls are CARP MASTER. Is there any way to force CARP to assume INIT state for some time when coming up, and only after X seconds either become MASTER or BACKUP ? Any other idea how to solve this, guys ? ___ freebsd...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to freebsd-pf-unsubscr...@freebsd.org Hello List, This is a follow-up to my original email quoted above. It seems that there is an existing bug in OpenBSD 3.8 and lower's CARP implementation which causes CARP interfaces to skip the INIT state altogether and start as MASTER if preempt is enabled. Source: https://calomel.org/pf_carp.html Quote: INIT : All CARP interfaces start in this state. Also, when a CARP interface is admin down, i.e. ifconfig em0 down, it is put into this state. When a CARP interface is admin up, it immediately transitions to BACKUP. Note that in OpenBSD 3.8 and earlier, a bug exists which will cause the host to transition to MASTER right away if preempt is enabled. I have been able to verify and reproduce this behavior on boxes running both 8.1 and 8.2 FreeBSD. Does anyone know what version of OpenBSD's CARP implementation we're running on FreeBSD 8.x ? It seems like this is the same bug, to me. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CARP interfaces and mastership issue
On 29 September 2011 14:20, Damien Fleuriot m...@my.gd wrote:
On 9/15/11 11:07 AM, Damien FLEURIOT wrote:
Hello list,
TLDR: carp interface becomes MASTER for a split second after being
created, even if another MASTER exists on the network with faster
advertisements. Breaks connections. HOWTO prevent ?
We've been experiencing this double mastership problem with CARP interfaces.
Allow me to put some context here:
2 firewalls, PF1, PF2, each with 2 VLANs (for example, some have more)
on a lagg device (link aggregation).
These firewalls then share virtual IPs through CARP interfaces, let us
assume the following:
PF1:
- vlan13
- vlan410
- carp13 (advskew 50)
- carp410 (advskew 50)
PF2:
- vlan13
- vlan410
- carp13 (advskew 100)
- carp410 (advskew 100)
CARP preemption is turned on, so that if vlan13 should fail on PF1, PF2
would assume mastership on both CARP interfaces.
Syscontrols below:
net.inet.carp.allow: 1
net.inet.carp.preempt: 1
net.inet.carp.log: 1
net.inet.carp.arpbalance: 0
net.inet.carp.suppress_preempt: 0
The problem we have is, say for example we reboot PF2.
When it comes back up, it will, even for a split second, assume CARP
mastership for its interfaces, at the same time as PF1.
This breaks existing sessions, openvpn tunnels and new client connections.
While I acknowledge the home-made demons should be built to support tiny
network outages, this doesn't solve our main problem.
We have the same issue when destroying/creating said CARP interfaces.
Recently we upgraded some switches' IOS version on our backup datacenter
(which also has 2 PF boxes, sharing the CARP IPs with the 2 PFs on our
production DC).
To prevent anything nasty happening, we forbade production VLANs on the
switches' uplink ports and only allowed management traffic to allow us
to perform the upgrade.
Things went smoothly but when we brought the production VLANs up again
at layer 2 on the switches, when spanning-tree converged we had again a
double MASTER problem.
I understand I could have avoided it by destroying/recreating the CARP
interfaces, but even in this case there is a split second during which
both firewalls are CARP MASTER.
Is there any way to force CARP to assume INIT state for some time when
coming up, and only after X seconds either become MASTER or BACKUP ?
Any other idea how to solve this, guys ?
___
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-pf
To unsubscribe, send any mail to freebsd-pf-unsubscr...@freebsd.org
Hello List,
This is a follow-up to my original email quoted above.
It seems that there is an existing bug in OpenBSD 3.8 and lower's CARP
implementation which causes CARP interfaces to skip the INIT state
altogether and start as MASTER if preempt is enabled.
Source:
https://calomel.org/pf_carp.html
Quote:
INIT : All CARP interfaces start in this state. Also, when a CARP
interface is admin down, i.e. ifconfig em0 down, it is put into this
state. When a CARP interface is admin up, it immediately transitions to
BACKUP. Note that in OpenBSD 3.8 and earlier, a bug exists which will
cause the host to transition to MASTER right away if preempt is enabled.
I have been able to verify and reproduce this behavior on boxes running
both 8.1 and 8.2 FreeBSD.
Does anyone know what version of OpenBSD's CARP implementation we're
running on FreeBSD 8.x ?
It seems like this is the same bug, to me.
Quick follow-up again.
This is the code for sys/netinet/ip_carp.c on FreeBSD 8.2, OpenBSD
3.8, OpenBSD 3.9 in function carp_setrun(struct carp_softc *sc,
sa_family_t af)
FREEBSD 8.2-PRERELEASE with init + preempt = auto MASTER bug
Function starts at line 1371.
---
switch (sc-sc_state) {
case INIT:
if (carp_opts[CARPCTL_PREEMPT] !carp_suppress_preempt) {
carp_send_ad_locked(sc);
carp_send_arp(sc);
#ifdef INET6
carp_send_na(sc);
#endif /* INET6 */
CARP_LOG(%s: INIT - MASTER (preempting)\n,
SC2IFP(sc)-if_xname);
carp_set_state(sc, MASTER);
carp_setroute(sc, RTM_ADD);
} else {
CARP_LOG(%s: INIT - BACKUP\n, SC2IFP(sc)-if_xname);
carp_set_state(sc, BACKUP);
carp_setroute(sc, RTM_DELETE);
carp_setrun(sc, 0);
}
break;
---
OPENBSD 3.8 with init + preempt = auto MASTER bug
Function starts at line 1293.
---
case INIT:
if (carp_opts[CARPCTL_PREEMPT] !carp_suppress_preempt) {
carp_set_state(sc, MASTER);
carp_setroute(sc, RTM_ADD);
carp_send_ad(sc);
carp_send_arp(sc
Re: CARP interfaces and mastership issue
Quick follow-up again.
This is the code for sys/netinet/ip_carp.c on FreeBSD 8.2, OpenBSD
3.8, OpenBSD 3.9 in function carp_setrun(struct carp_softc *sc,
sa_family_t af)
FREEBSD 8.2-PRERELEASE with init + preempt = auto MASTER bug
Function starts at line 1371.
---
switch (sc-sc_state) {
case INIT:
if (carp_opts[CARPCTL_PREEMPT] !carp_suppress_preempt) {
carp_send_ad_locked(sc);
carp_send_arp(sc);
#ifdef INET6
carp_send_na(sc);
#endif /* INET6 */
CARP_LOG(%s: INIT - MASTER (preempting)\n,
SC2IFP(sc)-if_xname);
carp_set_state(sc, MASTER);
carp_setroute(sc, RTM_ADD);
} else {
CARP_LOG(%s: INIT - BACKUP\n,
SC2IFP(sc)-if_xname);
carp_set_state(sc, BACKUP);
carp_setroute(sc, RTM_DELETE);
carp_setrun(sc, 0);
}
break;
---
OPENBSD 3.8 with init + preempt = auto MASTER bug
Function starts at line 1293.
---
case INIT:
if (carp_opts[CARPCTL_PREEMPT] !carp_suppress_preempt) {
carp_set_state(sc, MASTER);
carp_setroute(sc, RTM_ADD);
carp_send_ad(sc);
carp_send_arp(sc);
#ifdef INET6
carp_send_na(sc);
#endif /* INET6 */
} else {
carp_set_state(sc, BACKUP);
carp_setroute(sc, RTM_DELETE);
carp_setrun(sc, 0);
}
break;
---
OPENBSD 3.9 with bug fixed
Function starts at line 1348.
---
switch (sc-sc_state) {
case INIT:
carp_set_state(sc, BACKUP);
carp_setroute(sc, RTM_DELETE);
carp_setrun(sc, 0);
break;
---
It looks like the root cause is there.
I'll rebuild and test, keep you updated.
Find below my test results with the OpenBSD39 implementation which
forces an INIT - BACKUP transition regardless of preempt.
# sysctl net.inet.carp.preempt
net.inet.carp.preempt: 1
# sysctl net.inet.carp.suppress_preempt
net.inet.carp.suppress_preempt: 0
# ifconfig carp17
carp17: flags=8LOOPBACK metric 0 mtu 1500
inet 46.182.[snip] netmask 0x
inet 46.182.[snip] netmask 0x
inet 46.182.[snip] netmask 0x
inet 46.182.[snip] netmask 0x
inet 46.182.[snip] netmask 0x
carp: INIT vhid 117 advbase 1 advskew 200
# ifconfig carp17 up; ./check_carp17_status.sh
count: 0carp: BACKUP vhid 117 advbase 1 advskew 200
count: 1carp: BACKUP vhid 117 advbase 1 advskew 200
count: 2carp: BACKUP vhid 117 advbase 1 advskew 200
count: 3carp: BACKUP vhid 117 advbase 1 advskew 200
count: 4carp: BACKUP vhid 117 advbase 1 advskew 200
count: 5carp: BACKUP vhid 117 advbase 1 advskew 200
count: 6carp: BACKUP vhid 117 advbase 1 advskew 200
count: 7carp: BACKUP vhid 117 advbase 1 advskew 200
count: 8carp: BACKUP vhid 117 advbase 1 advskew 200
count: 9carp: BACKUP vhid 117 advbase 1 advskew 200
count: 10 carp: BACKUP vhid 117 advbase 1 advskew 200
# dmesg
carp17: INIT - BACKUP
carp17: link state changed to DOWN
Looks like it works.
I'm afraid I cannot test actual preemption by shutting down a physical
interface on the MASTER, because they're actually used in production and
I've got users logged in to their VPN on pf1.
I see no reason this should break anything however, it only forces the
CARP interface to assume a BACKUP state right after INIT, as it normally
should, regardless of preemption.
I'm filling a PR + patch.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CARP interfaces and mastership issue
On 18 Sep 2011, at 12:44, Patrick Lamaiziere patf...@davenulle.org wrote: Le Sat, 17 Sep 2011 23:40:06 -0400 (EDT), Brian Seklecki (Mobile) laval...@probikesllc.com a écrit : What would help here, is for a carp interface to wait a given delay (tunable through a sysctl ?) after creation or after being brought up I see now. The tunable sounds like a good idea; we should check OpenBSD, they probably already implemented something and we're behind. If not, a preempt dampener feature would be an awesome return feature. Might need to implment another state: MASTER-LISTENING (or LEARNING) ah a STP. OpenBSD uses a carp demote counter that prevents to become master (but it will become master anyway if there is not carp advertizement on the interface). There is a sysctl in FreeBSD but it's readonly. This is used to delay carp until pfsync synchronization is done and by daemons like bgpd. Anyway if carp becomes master when the interface is set up, it looks to be a bug on FreeBSD (and if you are sure that the problem does not come from the switch). This can be easily verified. When our vlan13 is forwarding on the switch, destroy and recreate the carp13 interface. It still assumes mastership during a short time, then yields and becomes backup.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
CARP interfaces and mastership issue
Posting to -stable since -pf didn't show much interest :/ Original Message Subject: CARP interfaces and mastership issue Date: Thu, 15 Sep 2011 11:07:37 +0200 Hello list, TLDR: carp interface becomes MASTER for a split second after being created, even if another MASTER exists on the network with faster advertisements. Breaks connections. HOWTO prevent ? We've been experiencing this double mastership problem with CARP interfaces. Allow me to put some context here: 2 firewalls, PF1, PF2, each with 2 VLANs (for example, some have more) on a lagg device (link aggregation). These firewalls then share virtual IPs through CARP interfaces, let us assume the following: PF1: - vlan13 - vlan410 - carp13 (advskew 50) - carp410 (advskew 50) PF2: - vlan13 - vlan410 - carp13 (advskew 100) - carp410 (advskew 100) CARP preemption is turned on, so that if vlan13 should fail on PF1, PF2 would assume mastership on both CARP interfaces. Syscontrols below: net.inet.carp.allow: 1 net.inet.carp.preempt: 1 net.inet.carp.log: 1 net.inet.carp.arpbalance: 0 net.inet.carp.suppress_preempt: 0 The problem we have is, say for example we reboot PF2. When it comes back up, it will, even for a split second, assume CARP mastership for its interfaces, at the same time as PF1. This breaks existing sessions, openvpn tunnels and new client connections. While I acknowledge the home-made demons should be built to support tiny network outages, this doesn't solve our main problem. We have the same issue when destroying/creating said CARP interfaces. Recently we upgraded some switches' IOS version on our backup datacenter (which also has 2 PF boxes, sharing the CARP IPs with the 2 PFs on our production DC). To prevent anything nasty happening, we forbade production VLANs on the switches' uplink ports and only allowed management traffic to allow us to perform the upgrade. Things went smoothly but when we brought the production VLANs up again at layer 2 on the switches, when spanning-tree converged we had again a double MASTER problem. I understand I could have avoided it by destroying/recreating the CARP interfaces, but even in this case there is a split second during which both firewalls are CARP MASTER. Is there any way to force CARP to assume INIT state for some time when coming up, and only after X seconds either become MASTER or BACKUP ? Any other idea how to solve this, guys ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CARP interfaces and mastership issue
On 15 September 2011 18:12, Brian Seklecki (Mobile) laval...@probikesllc.com wrote: Things went smoothly but when we brought the production VLANs up again at layer 2 on the switches, when spanning-tree converged we had again a double MASTER problem. In older versions of FBSD, creating logical interfaces like vlan(4) and carp(4) had an nasty inadvertent side effect of toggling the state of the underlying phyiscal interface. We're running quite the recent version really: FreeBSD 8.2-STABLE FreeBSD 8.2-STABLE #1: Thu Sep 1 15:51:49 CEST 2011 root@pf2-dmz:/usr/obj/usr/src/sys/FW amd64 This may be fixed in newer version. This would then then cause STP to reset on the switchport which can take up to 50 seconds to restore. Switchports are running portfast trunk with RPVST, this was a good candidate but sadly not the cause here. Also, physical interfaces do not get reset, dmesg is clean. In the mean time, the backup host hasn't heard from the master and assume the role of master. You can try turning on switchport spanning-tree portfast on your backup system which should cut down this time signifantly. If you can assure that no STP BPDUs will be announced from your CARP system, then its probably safe to run PortFast on a trunk. This is already done on all non-uplink ports, with portfast trunk as appropriate for servers that tag VLANs. The same is true after a reboot. Maybe hack the RC script to force the CARP interfaces on your backup to stay down at boot time for an extra 10/15 seconds Even then, once we bring the interface up (or create it), it seems to immediately assume mastership, breaking existing sessions on the main firewall, THEN it says it's received a more frequent advertisement and swaps to backup. What would help here, is for a carp interface to wait a given delay (tunable through a sysctl ?) after creation or after being brought up from down. This would allow the server to receive VRRP advertisements and immediately assume a BACKUP carp role upon boot or interface creation/up. This would also retain CARP's high reactivity to network failures and outages since this would only apply to a newly created/up'ed interface, not an already running one. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS directory with a large number of files
On 8/2/11 9:39 AM, seanr...@gmail.com wrote: Hi there, I Googled around and checked the PRs and wasn't successful in finding any reports of what I'm seeing. I'm hoping someone here can help me debug what's going on. On my FreeBSD 8.2-S machine (built circa 12th June), I created a directory and populated it over the course of 3 weeks with about 2 million individual files. As you might imagine, a 'ls' of this directory took quite some time. The files were conveniently named with a timestamp in the filename (still images from a security camera, once per second) so I've since moved them all to timestamped directories (/MM/dd/hh/mm). What I found though was the original directory the images were in is still very slow to ls -- and it only has 1 file in it, another directory. While not addressing your original question, which many people have already, I'll toss in the following: I do hope you've disabled access times on your ZFS dataset ? zfs set atime=off YOUR_DATASET/supercamera/captures ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ata: SIGNATURE: ffffffff
On 23 Jun 2011, at 01:02, George Kontostanos gkontos.m...@gmail.com wrote: Look, I think that this is getting personal and not constructive at all. Stop mumbling unless you have something useful to add. How about you do what he says and stop top posting, as per the list's policy ? Annoying pretty much everyone in the list with your stubbornness about top posting and your misplaced rudeness towards a helper might result in a drop in the number of people willing to spend time helping you. This being said, have you tried using a different PSU ?___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Networking - CARP interfaces
Hello list, Here I am today, setting up CARP interfaces on our backup firewalls, and I'm wondering something... Let's take the following scenario: Datacenter PRIM, firewall PRIM: - carp13 has public IPs X and Y and is master (advskew 100) Datacenter PRIM, firewall BACK: - carp13 has public IPs X and Y and is backup (advskew 150) Datacenter BACK, firewall PRIM: - carp13 has public IPs X, Y, W and Z (advskew 230, down) Datacenter BACK, firewall BACK: - carp13 has public IPs X, Y, W and Z (advskew 250, down) If I bring up my carp13 interfaces on the backup datacenter, will they become master because the carp interfaces on the primary datacenter is lacking 2 public IPs ? That would be a problem... Has anyone faced this situation before ? Also, adding IPs W and Z on my primary datacenter is not an option at the moment. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Networking - CARP interfaces
On 6/14/11 11:06 AM, Damien Fleuriot wrote: Hello list, Here I am today, setting up CARP interfaces on our backup firewalls, and I'm wondering something... Let's take the following scenario: Datacenter PRIM, firewall PRIM: - carp13 has public IPs X and Y and is master (advskew 100) Datacenter PRIM, firewall BACK: - carp13 has public IPs X and Y and is backup (advskew 150) Datacenter BACK, firewall PRIM: - carp13 has public IPs X, Y, W and Z (advskew 230, down) Datacenter BACK, firewall BACK: - carp13 has public IPs X, Y, W and Z (advskew 250, down) If I bring up my carp13 interfaces on the backup datacenter, will they become master because the carp interfaces on the primary datacenter is lacking 2 public IPs ? That would be a problem... Has anyone faced this situation before ? Also, adding IPs W and Z on my primary datacenter is not an option at the moment. Replying to myself, I can confirm that this scenario causes problems, see below: ### ON FIREWALL 1 , carp master for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.224.254 netmask 0xff00 carp: MASTER vhid 224 advbase 1 advskew 50 ### ON FIREWALL 2 , carp backup for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.234.254 netmask 0xff00 carp: BACKUP vhid 234 advbase 1 advskew 100 Now, I add a dummy IP to carp2 on FIREWALL 2, which is supposedly backup: ifconfig carp2 inet 192.168.234.207 alias Result: ### ON FIREWALL 1, carp master for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.224.254 netmask 0xff00 carp: MASTER vhid 224 advbase 1 advskew 50 ### ON FIREWALL 2, carp backup for carp0, carp1, but no longer carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.234.254 netmask 0xff00 inet 192.168.234.207 netmask 0xff00 carp: MASTER vhid 234 advbase 1 advskew 100 After I remove the extraneous IP, the interface becomes backup again: # This was a long time ago carp0: MASTER - BACKUP (more frequent advertisement received) carp0: link state changed to DOWN carp2: MASTER - BACKUP (more frequent advertisement received) carp2: link state changed to DOWN carp1: MASTER - BACKUP (more frequent advertisement received) carp1: link state changed to DOWN carp2: link state changed to DOWN # This was when I ran my tests carp2: INIT - MASTER (preempting) carp2: link state changed to UP carp2: MASTER - BACKUP (more frequent advertisement received) carp2: link state changed to DOWN This entails that hosts in a given carp vhid must have the exact same IP addresses configured on that interface. While this is perfectly understandable in a master-backup scenario, this is a bit more annoying for us in a master-backup + backup-backup scenario with 2 datacenters. I'll just have to adapt and ensure they have the same IP addresses then. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Networking - CARP interfaces
On 14 Jun 2011, at 19:33, Steve Polyack kor...@comcast.net wrote: On 06/14/2011 01:00 PM, Damien Fleuriot wrote: I can confirm that this scenario causes problems, see below: ### ON FIREWALL 1 , carp master for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.224.254 netmask 0xff00 carp: MASTER vhid 224 advbase 1 advskew 50 ### ON FIREWALL 2 , carp backup for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.234.254 netmask 0xff00 carp: BACKUP vhid 234 advbase 1 advskew 100 Now, I add a dummy IP to carp2 on FIREWALL 2, which is supposedly backup: ifconfig carp2 inet 192.168.234.207 alias Result: ### ON FIREWALL 1, carp master for carp0, carp1, carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.224.254 netmask 0xff00 carp: MASTER vhid 224 advbase 1 advskew 50 ### ON FIREWALL 2, carp backup for carp0, carp1, but no longer carp2 carp2: flags=49UP,LOOPBACK,RUNNING metric 0 mtu 1500 inet 192.168.234.254 netmask 0xff00 inet 192.168.234.207 netmask 0xff00 carp: MASTER vhid 234 advbase 1 advskew 100 After I remove the extraneous IP, the interface becomes backup again: # This was a long time ago carp0: MASTER - BACKUP (more frequent advertisement received) carp0: link state changed to DOWN carp2: MASTER - BACKUP (more frequent advertisement received) carp2: link state changed to DOWN carp1: MASTER - BACKUP (more frequent advertisement received) carp1: link state changed to DOWN carp2: link state changed to DOWN # This was when I ran my tests carp2: INIT - MASTER (preempting) carp2: link state changed to UP carp2: MASTER - BACKUP (more frequent advertisement received) carp2: link state changed to DOWN Did you give this enough time to reasonably settle? Sometimes when the interfaces initially come up, they will become MASTER for a bit before backing down. I think I did but I can do try again tomorrow evening just to make sure. Oh god, if only dmesg entries were timestamped... This entails that hosts in a given carp vhid must have the exact same IP addresses configured on that interface. While this is perfectly understandable in a master-backup scenario, this is a bit more annoying for us in a master-backup + backup-backup scenario with 2 datacenters. I'll just have to adapt and ensure they have the same IP addresses then. I have a suspicion that the important part may be the number of IP addresses on the CARP interface. If CARP sends an advertisement from each IP alias on a CARP interface, then I think that would explain what you are seeing - and also possibly give you a workaround by adding two more bogus IPs on your primary datacenter firewalls (where IPs W and Z are normally missing). - Steve I'll give it a try, although I think in a scenario where the carp interfaces have the same number of IPs and these IPs differ, both interfaces will claim mastership. Will post results.___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Cleaning temporary build tree failed
On 4/9/11 9:25 AM, David Marec wrote: Hi guys. Since the release of FreeBSD 8.2, building world fails on the following error: -- david:/home/david#cd /usr/src david:/usr/src#make -j4 buildworld make kernel -- World build started on Sat Apr 9 09:16:50 CEST 2011 -- -- Rebuilding the temporary build tree -- rm -rf /usr/obj/usr/src/tmp rm -rf /usr/obj/usr/src/lib32 rm: /usr/obj/usr/src/lib32/usr/lib32/libc.so.7: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libcrypt.so.5: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libthr.so.3: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/librt.so.1: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32: Directory not empty rm: /usr/obj/usr/src/lib32/usr: Directory not empty rm: /usr/obj/usr/src/lib32: Directory not empty *** Error code 1 1 error *** Error code 2 1 error david:/usr/src#ls -lo /usr/obj/usr/src/lib32/usr/lib32/ total 1262 -r--r--r-- 1 root wheel schg 1143468 22 mar 21:19 libc.so.7 -r--r--r-- 1 root wheel schg 32060 22 mar 21:19 libcrypt.so.5 -r--r--r-- 1 root wheel schg 16412 22 mar 21:22 librt.so.1 -r--r--r-- 1 root wheel schg 76412 22 mar 21:20 libthr.so.3 -- Im a running FreeBSD 8.2-Stable for amd64. So, before building world, i have to change the flags for the files above. There was no need to do this before. Any idea to get rid of this issue ? I experience no such problems on *many* boxes running 8.2 at work here. You will want to: chflags -R noschg /usr/obj/ cd /usr/src make -j4 buildworld make buildkernel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Port 80 closed?
On 3/8/11 11:52 PM, Dave Johnson wrote: Hi all An IPFW problem? An help gladly accepted It would appear Port 80 closed Ports 21 25 443 587 998 work well rc.conf defaultrouter=192.168.0.1 gateway_enable=YES hostname=xxx.xxx.xxx ifconfig_re0=inet 192.168.0.11 netmask 255.255.255.0 ifconfig_re1=inet 192.168.1.2 netmask 255.255.255.0 keymap=us.iso moused_enable=YES sshd_enable=YES firewall_enable=YES firewall_script=/etc/rc.firewall natd_program=/sbin/natd natd_enable=YES natd_interface=re0 natd_flags=-f /etc/natd.conf dhcpd_enable=NO dhcpd_flags=-q dhcpd_conf=/usr/local/etc/dhcpd.conf dhcpd_ifaces=re1 dhcpd_withumask=022 natd.conf interface re0 use_sockets yes same_ports yes log #redirect_port tcp 192.168.1.189:3389 3389 #redirect_port tcp 192.168.1.53:5500 5500 #!/bin/sh /sbin/ipfw -f flush /sbin/ipfw -f pipe flush #Nat Rules /sbin/ipfw add 10 allow ip from 127.0.0.1 to 127.0.0.1 via lo0 /sbin/ipfw add 30 divert natd all from any to any via re0 #Forward to Transparent Proxy Server #/sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 #/sbin/ipfw add 10010 fwd 127.0.0.1,3128 tcp from 10.0.21.2 to any 80 /sbin/ipfw add 10001 fwd 127.0.0.1,3128 tcp from any to any 80 /sbin/ipfw add 5 allow ip from any to any Regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org Hi Dave, First of all, I'd suggest you explain what you're trying to do. From your IPFW conf I can only guess you're trying to set up a transparent proxy. How do you test to see if the port is open or not ? Is your squid instance running and configured for transparent forwarding with IPFW ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: 7.2 to RELENG_8 boot lockup
On 3/7/11 2:33 PM, Randy Bush wrote: 18 month old 7.2 FreeBSD dfw1.psg.com 7.2-STABLE FreeBSD 7.2-STABLE #1: Sat Aug 22 08:37:36 UTC 2009 r...@dfw1.psg.com:/usr/obj/usr/src/sys/DFW1 amd64 csup and o make buildworld o make kernel o boot single user o locks up right after beastie, one twirly and locked boot verbose is reticent reset, boot to old kernel, all normal how to debug? randy I would advise you build a *generic* 8.x kernel, as opposed to the custom one you seem to be using, first thing. I would also recommend you see and try if you can sell domain name psg.com to the french Paris Saint Germain football club for a couple million euros. -- dam ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ZFS - abysmal performance with samba since upgrade to 8.2-RELEASE
On 24 February 2011 08:55, Jeremy Chadwick free...@jdc.parodius.com wrote: On Thu, Feb 24, 2011 at 08:30:17AM +0100, Damien Fleuriot wrote: Hello list, I've recently upgraded my home box from 8.2-PRE to 8.2-RELEASE and since then I've been experiencing *abysmal* performance with samba. We're talking transfer rates of say 50kbytes/s here, and I'm the only client on the box. I have a similar system with significantly less disks (two pools, one disk each; yes, no redundancy). The system can push, via SMB/CIFS across the network about 65-70MBytes/sec, and 80-90MByte/sec via FTP. I'll share with you my tunings for Samba, ZFS, and the system. I spent quite some time messing with different values in Samba and FreeBSD to find out what got me the best performance without destroying the system horribly. Please note the amount of memory matters greatly here, so don't go blindly setting these if your system has some absurdly small amount of physical RAM installed. Before getting into what my system has, I also want to make clear that there have been cases in the past where people were seeing abysmal performance from ZFS, only to find out it was a *single disk* in their pool which was causing all of the problems (meaning a single disk was performing horribly, impacting everything). I can try to find the mailing list post, but I believe the user offlined the disk (and later replaced it) and everything was fast again. Just a FYI. System specifications === * Case - Supermicro SC733T-645B * MB - Supermicro X7SBA * CPU - Intel Core 2 Duo E8400 * RAM - CT2KIT25672AA800, 4GB ECC * RAM - CT2KIT25672AA80E, 4GB ECC * Disk - Intel X25-V SSD (ada0, boot) * Disk - WD1002FAEX (ada1, ZFS data pool) * Disk - WD2001FASS (ada2, ZFS backups pool) Samba === Rebuild the port (ports/net/samba35) with AIO_SUPPORT enabled. To use AIO you will need to load the aio.ko kernel module (kldload aio) first. Relevant smb.conf tunings: [global] socket options = TCP_NODELAY SO_SNDBUF=131072 SO_RCVBUF=131072 use sendfile = no min receivefile size = 16384 aio read size = 16384 aio write size = 16384 aio write behind = yes ZFS pools === pool: backups state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM backups ONLINE 0 0 0 ada2 ONLINE 0 0 0 errors: No known data errors pool: data state: ONLINE scrub: none requested config: NAME STATE READ WRITE CKSUM data ONLINE 0 0 0 ada1 ONLINE 0 0 0 errors: No known data errors ZFS tunings === Your tunings here are wild (meaning all over the place). Your use of vfs.zfs.txg.synctime=1 is probably hurting you quite badly, in addition to your choice to enable prefetching (every ZFS FreeBSD system I've used has benefit tremendously from having prefetching disabled, even on systems with 8GB RAM and more). You do not need to specify vm.kmem_size_max, so please remove that. Keeping vm.kmem_size is fine. Also get rid of your vdev tunings, I'm not sure why you have those. My relevant /boot/loader.conf tunings for 8.2-RELEASE (note to readers: the version of FreeBSD you're running, and build date, matters greatly here so do not just blindly apply these without thinking first): # We use Samba built with AIO support; we need this module! aio_load=yes # Increase vm.kmem_size to allow for ZFS ARC to utilise more memory. vm.kmem_size=8192M vfs.zfs.arc_max=6144M # Disable ZFS prefetching # http://southbrain.com/south/2008/04/the-nightmare-comes-slowly-zfs.html # Increases overall speed of ZFS, but when disk flushing/writes occur, # system is less responsive (due to extreme disk I/O). # NOTE: Systems with 8GB of RAM or more have prefetch enabled by # default. vfs.zfs.prefetch_disable=1 # Decrease ZFS txg timeout value from 30 (default) to 5 seconds. This # should increase throughput and decrease the bursty stalls that # happen during immense I/O with ZFS. # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007343.html # http://lists.freebsd.org/pipermail/freebsd-fs/2009-December/007355.html vfs.zfs.txg.timeout=5 sysctl tunings === Please note that the below kern.maxvnodes tuning is based on my system usage, and yours may vary, so you can remove or comment out this option if you wish. The same goes for vfs.ufs.dirhash_maxmem. As for vfs.zfs.txg.write_limit_override, I strongly suggest you keep this commented out for starters; it effectively rate limits ZFS I/O, and this smooths out overall performance (otherwise I was seeing what appeared to be incredible network transfer speed, then the system would churn hard for quite some time on physical I/O, then fast network speed, physical I/O
Re: ZFS - abysmal performance with samba since upgrade to 8.2-RELEASE
On 2/24/11 8:55 AM, Jeremy Chadwick wrote: On Thu, Feb 24, 2011 at 08:30:17AM +0100, Damien Fleuriot wrote: Hello list, I've recently upgraded my home box from 8.2-PRE to 8.2-RELEASE and since then I've been experiencing *abysmal* performance with samba. We're talking transfer rates of say 50kbytes/s here, and I'm the only client on the box. I have a similar system with significantly less disks (two pools, one disk each; yes, no redundancy). The system can push, via SMB/CIFS across the network about 65-70MBytes/sec, and 80-90MByte/sec via FTP. I'll share with you my tunings for Samba, ZFS, and the system. I spent quite some time messing with different values in Samba and FreeBSD to find out what got me the best performance without destroying the system horribly. Please note the amount of memory matters greatly here, so don't go blindly setting these if your system has some absurdly small amount of physical RAM installed. Before getting into what my system has, I also want to make clear that there have been cases in the past where people were seeing abysmal performance from ZFS, only to find out it was a *single disk* in their pool which was causing all of the problems (meaning a single disk was performing horribly, impacting everything). I can try to find the mailing list post, but I believe the user offlined the disk (and later replaced it) and everything was fast again. Just a FYI. [SNIP] Good luck. It is fun because when I wrote my original email, I thought about both you and mm@ Thanks a lot for your very detailed response, I will try these out and post feedback :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
PR - submitting a patch
Hello list, I apologize for this very trivial question but I can't seem to find the answer in the doc: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pr-guidelines/article.html I have submitted a PR late december 2k10 and it's still in open state: http://www.freebsd.org/cgi/query-pr.cgi?pr=153357 Since the fix is so very trivial, I would like to submit a .patch file. What is the proper procedure to follow, or person to contact ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: PR - submitting a patch
Cheers, I've done just that :) On 2/24/11 12:26 PM, Rodrigo OSORIO (ros) wrote: Hi, If the patch solves the PR, attach it to the PR submiting a followup (you have a link for this in the bottom of the PR webpage). This should be a good way to bump the PR. Regards, Rodrigo On 24/02/11 12:03 +0100, Damien Fleuriot wrote: Hello list, I apologize for this very trivial question but I can't seem to find the answer in the doc: http://www.freebsd.org/doc/en_US.ISO8859-1/articles/pr-guidelines/article.html I have submitted a PR late december 2k10 and it's still in open state: http://www.freebsd.org/cgi/query-pr.cgi?pr=153357 Since the fix is so very trivial, I would like to submit a .patch file. What is the proper procedure to follow, or person to contact ? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ZFS - abysmal performance with samba since upgrade to 8.2-RELEASE
Hello list, I've recently upgraded my home box from 8.2-PRE to 8.2-RELEASE and since then I've been experiencing *abysmal* performance with samba. We're talking transfer rates of say 50kbytes/s here, and I'm the only client on the box. I've seen here and there discussions about sendfile's support, and how it is recommended to disable it in samba. Now, the man tells us: Default: use sendfile = false On the other side, FTP and SFTP transfers are OK, at 20mbytes/s or so. Find below a bit of info smb.conf --- [global] workgroup = MYGROUP server string = Samba Server security = user hosts allow = 192.168.0.1 192.168.1.1 fe80::1 load printers = no log file = /var/log/samba/log.%m max log size = 50 # You may want to add the following on a Linux system: socket options = SO_RCVBUF=8192 SO_SNDBUF=8192 dns proxy = no bind interfaces only = yes interfaces = re0 lagg0 hide unreadable = yes [homes] comment = Home Directories browseable = no writable = yes loader.conf --- # Tune ZFS somewhat aye ? vm.kmem_size=3072M vm.kmem_size_max=3072M vfs.zfs.arc_min=128M vfs.zfs.arc_max=2048M vfs.zfs.txg.synctime=1 vfs.zfs.prefetch_disable=0 vfs.zfs.vdev.min_pending=4 vfs.zfs.vdev.max_pending=8 ZFS pool --- nas# zpool status pool: rtank state: ONLINE status: The pool is formatted using an older on-disk format. The pool can still be used, but some features are unavailable. action: Upgrade the pool using 'zpool upgrade'. Once this is done, the pool will no longer be accessible on older software versions. scrub: none requested config: NAME STATE READ WRITE CKSUM rtank ONLINE 0 0 0 raidz2 ONLINE 0 0 0 gpt/zfs-ada0 ONLINE 0 0 0 gpt/zfs-ada1 ONLINE 0 0 0 gpt/zfs-ada2 ONLINE 0 0 0 gpt/zfs-ada3 ONLINE 0 0 0 gpt/zfs-ad14 ONLINE 0 0 0 gpt/zfs-ad10 ONLINE 0 0 0 gpt/zfs-ad11 ONLINE 0 0 0 gpt/zfs-ad12 ONLINE 0 0 0 gpt/zfs-ad13 ONLINE 0 0 0 zpool version 14 zfs version 3 So , sendfile disabled, ZFS pool not quite updated, good FTP/ssh performance, horribad samba performance. Does anyone have an idea of stuff I should be looking at ? Again, this has only begun since I've upgraded from 8.2-PRE/RC3 to 8.2-RELEASE. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: mps(4) driver (LSI 6Gb SAS) commited to stable/8
On 2/18/11 5:42 PM, Kenneth D. Merry wrote: Let me know if you run into any issues. Ken Rebuilt this afternoon, rebooted, still works fine. I'll post if I run into any problem. Thanks for your work, this driver was clearly needed on 8.x seeing the cards are becoming more and more mainstream. Too bad it didn't make the 8.2 ISO images :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
On 2/18/11 5:49 PM, Kenneth D. Merry wrote: On Thu, Feb 17, 2011 at 11:07:21 -0800, Rumen Telbizov wrote: Hello Damien, list: Anyway this was just my humble attempt to encourage the MFC of this driver. I think the card is pretty good. I'd like to hear other people's opinion on this HBA though. MFC is done, try it out and let me know if there are any problems. Thanks, Ken CVSup'ing as we speak ;) When you say -stable, I assume that's 8.2-RC3 yes ? I'm not very familiar with the whole CVSup / MFC / release process... ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
On 2/18/11 6:28 PM, Kevin Oberman wrote: Date: Fri, 18 Feb 2011 09:57:11 -0700 From: Kenneth D. Merry k...@freebsd.org Sender: owner-freebsd-sta...@freebsd.org On Fri, Feb 18, 2011 at 17:53:11 +0100, Damien Fleuriot wrote: On 2/18/11 5:49 PM, Kenneth D. Merry wrote: On Thu, Feb 17, 2011 at 11:07:21 -0800, Rumen Telbizov wrote: Hello Damien, list: Anyway this was just my humble attempt to encourage the MFC of this driver. I think the card is pretty good. I'd like to hear other people's opinion on this HBA though. MFC is done, try it out and let me know if there are any problems. Thanks, Ken CVSup'ing as we speak ;) When you say -stable, I assume that's 8.2-RC3 yes ? No, that is in a separate branch that is frozen. This won't be in 8.2, we would have had to have gotten it in in December to make 8.2. This is in stable/8. I'm not very familiar with the whole CVSup / MFC / release process... To be very clear, stable/8 is tagged RELENG_8 in cvs, so you need to specify a tag of RELENG_8 in your supfile. *default release=cvs tag=RELENG_8 Hi Kevin and thanks for your reply, As I just told Kenneth (switched to private exchanges to not spam the list with meaningless stuff), I'm afraid I don't get a sys/dev/mps/ folder when I sync against RELENG_8 nas# grep release /etc/cvsup/stable-supfile *default release=cvs tag=RELENG_8 #src-release nas# ls -lad /usr/src/sys/dev/mp* drwxr-xr-x 3 root wheel 512 Feb 18 19:17 /usr/src/sys/dev/mpt Oh wait, it occurs to me the mirror I sync on might not be up to date yet... SUPHOST=cvsup1.fr.freebsd.org SUPFILE=/etc/cvsup/stable-supfile ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
On 2/17/11 12:10 PM, Oliver Brandmueller wrote: Hi, On Thu, Feb 17, 2011 at 12:07:17PM +0100, Damien Fleuriot wrote: It looks rather unhappy: mybsd root /usr/ports/sysutils/smartmontools # /usr/local/sbin/smartctl -a /dev/da0 smartctl 5.40 2010-10-16 r3189 [FreeBSD 8.2-RC3 amd64] (local build) Copyright (C) 2002-10 by Bruce Allen, http://smartmontools.sourceforge.net /dev/da0: No such file or directory Smartctl: please specify device type with the -d option. Thanx for the test and the quick reply! I'm really getting crazy on this. All the SAS controllers seems to have nifty RAID features and stuff... *sigh* Thanx again, Oliver What is sad is that these controllers are becoming very mainstream now, we're getting them more and more on Dell servers , and the fbsd project still struggles with them (for reasons I don't know, might be LSI's fault, might be a lack of resources or interest...) I'm having a very hard time defending the use of fbsd for firewalls at work, with the recent release of debian kfreebsd. What's saving fbsd for the moment is the lack of a proper CARP implementation on debian kfree. Actually, cc'ing the list, I'd like to share my feelings on this. @list: I'm trying very hard to keep freebsd at work for our firewalls. Recently, I installed new blade servers shipping with h700 controllers (these attached to mfi w/o problems). If, for some reason, we get h200 cards using the mps driver, I'll have to install using software RAID instead. This would be a *disaster* and extremely hard for me to justify to my boss. The staff in the datacenters check the machines every day, making a routing inspection to ensure no server has orange warning lights. Typically when a hardware RAID's hard drive fails, the lights go orange thus prompting them to warn us (in case we missed the nagios alert) for a replacement. If I had to use software RAID, we'd be giving up on this extra security and, again, I'd have a very hard time justifying it. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: LSI SAS 2008 (mfi) on SuperMicro X8SI6-F
On 2/17/11 1:18 PM, Tom Evans wrote: On Thu, Feb 17, 2011 at 12:11 PM, Damien Fleuriot m...@my.gd wrote: What is sad is that these controllers are becoming very mainstream now, we're getting them more and more on Dell servers , and the fbsd project still struggles with them (for reasons I don't know, might be LSI's fault, might be a lack of resources or interest...) I'm having a very hard time defending the use of fbsd for firewalls at work, with the recent release of debian kfreebsd. Forgive my naïveté, but surely kfreebsd would have precisely the same issues with the same controllers, since it uses FreeBSD's kernel. Am I missing something? Cheers Tom I am not sure, but you make a good point. Don't get me wrong though, I don't mean to offend anyone when I say the fbsd project struggles with this driver. There may very well be very valid reasons like lack of cooperation on LSI's part, I wouldn't know. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
