Ethernet interface Watchdog timeout
Last night I needed to reboot switches connected to a FreeBSD server. There are two igb interfaces, bound via lagg0 as an LACP pair. Each is connected to a different switch and those switches support mlag (LAG distributed across more than one switch unit). One of the interfaces came back fine when its switch rebooted, but when the second switch was rebooted several hours later the other interface didn't. Both igb0 and igb1 interfaces are on the motherboard itself. This has happened once before, and rebooting the FreeBSD server resolved it. Obviously I'd like to understand the problem better first. Is there more debugging I could collect while the server is in this state? Physically removing the ethernet cable and plugging it back in does not bring the interface up. ifconfig down and up also does not help. What is this watchdog timeout that we are seeing in the logs? Ari # ifconfig igb0 igb0: flags=8c03 metric 0 mtu 1500 options=e507bb ether ac:1f:6b:00:ea:b2 media: Ethernet autoselect status: no carrier nd6 options=29 # uname -a FreeBSD lash.internal 12.1-RELEASE-p2 FreeBSD 12.1-RELEASE-p2 GENERIC amd64 # grep igb0 /var/log/messages Jul 8 23:00:43 lash kernel: igb0: Watchdog timeout (TX: 0 desc avail: 42 pidx: 1003) -- resetting Jul 8 23:00:43 lash kernel: igb0: link state changed to DOWN Jul 8 23:00:44 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul 9 00:00:01 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul 9 05:01:12 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul 9 05:06:56 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul 9 14:25:33 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting Jul 9 14:44:30 lash kernel: igb0: Watchdog timeout (TX: 7 desc avail: 1024 pidx: 0) -- resetting igb0@pci0:1:0:0: class=0x02 card=0x152115d9 chip=0x15218086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = 'I350 Gigabit Network Connection' class = network subclass = ethernet cap 01[40] = powerspec 3 supports D0 D3 current D0 cap 05[50] = MSI supports 1 message, 64 bit, vector masks cap 11[70] = MSI-X supports 10 messages, enabled Table in map 0x1c[0x0], PBA in map 0x1c[0x2000] cap 10[a0] = PCI-Express 2 endpoint max data 256(512) FLR NS link x4(x4) speed 5.0(5.0) ASPM disabled(L0s/L1) ecap 0001[100] = AER 2 0 fatal 0 non-fatal 1 corrected ecap 0003[140] = Serial 1 ac1f6b00eab2 ecap 000e[150] = ARI 1 ecap 0010[160] = SR-IOV 1 IOV disabled, Memory Space disabled, ARI disabled 0 VFs configured out of 8 supported First VF RID Offset 0x0180, VF RID Stride 0x0004 VF Device ID 0x1520 Page Sizes: 4096 (enabled), 8192, 65536, 262144, 1048576, 4194304 ecap 0017[1a0] = TPH Requester 1 ecap 0018[1c0] = LTR 1 ecap 000d[1d0] = ACS 1 # dmidecode -t baseboard # dmidecode 3.2 Scanning /dev/mem for entry point. SMBIOS 3.0 present. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: Supermicro Product Name: X10DRW-i Version: 1.02 Serial Number: NM173S002991 Asset Tag: Default string Features: Board is a hosting board Board is replaceable Location In Chassis: Default string Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0021, DMI type 41, 11 bytes Onboard Device Reference Designation: ASPEED Video AST2400 Type: Video Status: Enabled Type Instance: 1 Bus Address: :05:00.0 Handle 0x0022, DMI type 41, 11 bytes Onboard Device Reference Designation: Intel Ethernet i350 #1 Type: Ethernet Status: Enabled Type Instance: 1 Bus Address: :01:00.0 Handle 0x0023, DMI type 41, 11 bytes Onboard Device Reference Designation: Intel Ethernet i350 #2 Type: Ethernet Status: Enabled Type Instance: 2 Bus Address: :01:00.1 ___ 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: Java support
On 22/2/19 4:12pm, Charlie Li wrote: I don't think this is beyond the open source community's capabilities at all; quite the opposite. The real crux is individual priorities. Right now there is no publicly visible work on porting Java 11 (the only version worth working on at this time I think). Someone may step up when it becomes important enough to them. Or not. Please refer to the following PR: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222568 The last comment there is exactly the point of what I had typed in an earlier incarnation of this email message before I had some second thoughts on just how rude it could come off. Yeah, not especially helpful. Not everyone with a need for new Java has the technical expertise to work on something as complex as porting a JVM. I have considerable experience working in open source communities and I know that the right confluence of people and tasks are not always something you can predict. I was hoping that either the FreeBSD Foundation might step up to this problem or else some contributors might discuss efforts happening behind closed doors. However I do think that a lack of modern Java is going to bite into the credibility of FreeBSD as a server platform before long. Are the sponsors behind the AdoptOpenJDK project interested in FreeBSD as a platform? Are there conversations happening there to try and get FreeBSD including in their test farm? Can the FreeBSD project assist by making servers available, especially with the rumours of Travis downsizing? Cheers Ari [1] https://adoptopenjdk.net/sponsors.html ___ 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: Java support
On 21/2/19 9:18pm, Kurt Jaeger wrote: Are there plans for the Foundation to sponsor some work in this area? Your point is, that the FreeBSD community should do regular testbuilds for https://github.com/AdoptOpenJDK/openjdk-jdk9u/ https://github.com/AdoptOpenJDK/openjdk-jdk10u/ https://github.com/AdoptOpenJDK/openjdk-jdk11u/ and provide patches if something does not build or work, right ? And, if necessary, fund someone to do that work ? Yes. Although I don't think there is a need to worry about the short term releases 9 and 10. Only the LTS branches like JDK11 are being supported by many OS vendors. https://access.redhat.com/articles/1299013 My concern is that it might be beyond the capability of the open source community to do the amount of work required here in a timely manner, and so this might be an opportunity for the Foundation to step in and and ensure this vital work is done. Perhaps ongoing maintenance is easier once AdoptOpenJDK is brought up to speed on the BSD bits required. Functioning Java is (IMO) a critical part of a modern server operating system. Cheers Ari ___ 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"
Java support
Hi everyone With the Java FreeBSD mailing list pretty quiet, I thought I might ask here whether anyone was working on porting the latest Java versions over to FreeBSD. There is of coursethe https://adoptopenjdk.net/project, but there is little activity immediately obvious on porting there [1]. While Java 8 will be quite satisfactory for a while, the longer Java advances without BSD patches the harder it will be to bring across all the good work done for Java 8 on FreeBSD. Are there plans for the Foundation to sponsor some work in this area? I'm guessing its pretty substantial. Cheers Ari [1] https://github.com/AdoptOpenJDK/openjdk-jdk11u/search?o=desc&q=bsd&s=committer-date&type=Commits ___ 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-update IDS: fixing errors
I'd like to use "freebsd-update IDS" as a simple intrusion check. I have a separate mechanism to test that freebsd-update itself hasn't been modified. However I get lots of lines like this: /usr/share/man/man4/if_ixgbe.4.gz has SHA256 hash 859cc19faf7a511755409aa143b24ccb2c998bbc99a5972d1d7aa70f37611a65, but should have SHA256 hash 5652698ae3834e8cfbb2d0e5a95fe7984a6656f0a6c792e88ea8f2c75873555e. Two questions: 1. What causes these mismatches? Does IDS not take into account minor updates or something else? 2. Is there a simple way to fix this that doesn't involve a system reinstall? Just unzip the FreeBSD tz files and copy over the relevant bits? Could that be added as a feature to the IDS command? Ari ___ 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: pf best practices: in or out
On 25/6/18 5:30pm, Walter Parker wrote: The use case for pass out rules would be to block local processes on the box from making external connections to other servers. This is useful if you don't fully trust users or software running on your equipment. Also, this would useful to preemptively block ports that would be useful in DDOS attacks. Ah, then I misunderstood what pass-in and pass-out meant. I thought those words referred to the interface, so it would hit pass-in to the interface even if coming from a local process. In that case I'm better writing all my outbound rules as pass-out so as to equally filter traffic from the internal network and local firewall machine. Ari ___ 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: pf best practices: in or out
Thanks Jason, So in essence, you'd just control everything on the 'pass in'. I'm assuming all traffic originating from the local machine is still hitting a pass in rule on some interface corresponding to the source IP address? DNAT is working fine for me in pf, although I understand it is named rdr. What is the use case for using pass out rules instead of pass in rules? Cheers Ari On 25/6/18 4:55pm, Jason Tubnor wrote: Hi Ari, In most cases, block all and then perform conditional pass in on traffic. Depending on your requirements you would conclude your rules with explicit pass out or just a general pass out 'all' (the former in the newer syntax of PF allows you to control queues, operational tags etc - but that won't help you with the current implementation of PF in FreeBSD). DNAT isn't a thing in PF (I assume you were looking how you'd do it if you were coming from Linux). Incoming will manipulate where required when rdr etc. Only outbound needs NAT binding. Cheers, Jason. On 25 June 2018 at 14:12, Aristedes Maniatis <mailto:a...@ish.com.au>> wrote: Hi all pf has rules that can operate either 'in' or 'out'. That is, on traffic entering or leaving an interface. I'm trying to consolidate my rules to make them easier to understand and update, so it seems a bit pointless to have the same rules twice. Are there any best practices on whether it makes more sense to put rules on the in or out side? I could bind all the rules to the internet facing interface and then use "in" for inbound traffic and "out" for outbound. Does that makes sense? Does it make any difference from a performance point of view? Secondly, where do DNAT rules execute in the sequence? Do they change the destination IP in between the in and out pass pf rules? I'm not currently subscribed here, so please cc me on replies. Thanks Ari ___ freebsd-stable@freebsd.org <mailto:freebsd-stable@freebsd.org> mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable <https://lists.freebsd.org/mailman/listinfo/freebsd-stable> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org <mailto:freebsd-stable-unsubscr...@freebsd.org>" -- "If my calculations are correct, when this baby hits 88MPH, you're gonna to see some serious shit" - Emmett "Doc" Brown ___ 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"
pf best practices: in or out
Hi all pf has rules that can operate either 'in' or 'out'. That is, on traffic entering or leaving an interface. I'm trying to consolidate my rules to make them easier to understand and update, so it seems a bit pointless to have the same rules twice. Are there any best practices on whether it makes more sense to put rules on the in or out side? I could bind all the rules to the internet facing interface and then use "in" for inbound traffic and "out" for outbound. Does that makes sense? Does it make any difference from a performance point of view? Secondly, where do DNAT rules execute in the sequence? Do they change the destination IP in between the in and out pass pf rules? I'm not currently subscribed here, so please cc me on replies. Thanks Ari ___ 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: ABI changes within stable branch
On 20/9/17 11:33AM, Warner Losh wrote:
> FreeBSD has always had a policy of backwards compatibility. By that
> definition we are stable. What we don't promise is full forwards
> compatibility, which is what you are asking for.
Correct. Within the stable branch I'd always assumed forward compatibility was
the case and haven't been bitten by this since my days of FreeBSD 3.0.
But even if this is no longer the case (or was never a goal), I'm still
confused by versioning packages like this: http://pkg.FreeBSD.org/${ABI}/ which
is clearly not correct. There is just no way for me to discover which package
is compatible with which OS version.
Anyhow, thanks for listening. This is putting a dent in my adoption of the
accelerated EOL of minor releases. At the very least I need to remember to keep
poudriere on the x.0 release even after it is EOL, until every one of my
servers has been upgraded (which is rarely before the new accelerated EOL for
machines that don't face the internet).
Ari
--
------>
Aristedes Maniatis
CEO, ish
https://www.ish.com.au
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
___
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: ABI changes within stable branch
Matthew Seaman wrote:
>
> Ports are still being built according to the same policy -- on the
> earliest still-supported release of each major branch.
>
> It's just that now, for 11.x and subsequent, 11.0 goes out of support a
> month or so after 11.1-RELEASE comes out. You're meant to have upgraded
> by now. The 11.0 -> 11.1 upgrade is intended to be a pretty routine
> thing that you can do about as freely as you can apply a security patch
> or other update within the 11.0 series.
I'm afraid this hasn't made things clearer for me at all.
1. What does the "stable" branch mean if the ABI is no longer stable
2. This policy of changing the ABI means that upgrading from 11.0 to 11.1 is
now less routine than it used to be in the old days. Each minor update is more
like the effort involved in upgrading 10 -> 11. So I'll be doing it less often,
not more often.
3. Packages are located in a namespace like this:
https://pkg.freebsd.org/freebsd:11:x86:64 But now I don't know which release
this is actually pointing to or which packages will work.
4. /etc/pkg/repos/FreeBSD.conf points to url:
"pkg+http://pkg.FreeBSD.org/${ABI}/quarterly"; However this is now wrong. If I
am delayed in upgrading my system, downloading packages from there will
sometimes break things. And I will not know until runtime.
5. The package MANIFEST contains information about system compatibility. That
is just the major version, but we need the minor release version now too.
Here are some possible solutions from where I'm sitting on the edges:
a. Go back to 'stable' meaning the ABI doesn't change. Not just the kernel, but
the whole OS.
b. Since there is no different in breakage and effort when going from 11.0 ->
11.1 or when going from 11.0 -> 12.0, just get rid of the point releases
entirely. Then the existing packaging system still works.
c. Add point releases to the package manifest. We've have something like
https://pkg.freebsd.org/freebsd:11.0:x86:64
d. Wait for some new base packaging magic to solve things.
Have I summarised this effectively?
Ari
--
-->
Aristedes Maniatis
CEO, ish
https://www.ish.com.au
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
___
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: ABI changes within stable branch
On 19/9/17 6:15PM, Kurt Jaeger wrote: > Hi! > >> Now that we are on a faster upgrade policy for minor branches, it is >> expected that we'll upgrade from 11.0 to 11.1 to 11.2 much faster than in >> the old days. I can cope with that, but it appears that functional changes >> are also being made within the stable branch as seen here: >> >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221672 >> >> A new fdatasync() method is available in 11.1 but not in 11.0 which means >> that I now need to maintain separate ports trees for each minor update. I've >> never done this before, assuming (correctly for me until now) that all ports >> build on the latest minor release within the stable branch would work on >> older releases until I was ready to upgrade them. > > I think it was the other way around: All ports build on the .0 of > a RELEASE work on all later .x of that RELEASE. Which makes it a bit > difficult, if a .0 is no longer supported/patched by the secteam. > > A pointer to the official policy would be nice 8-} Then we have a problem since https://pkg.freebsd.org/freebsd:11:x86:64/latest/All/ has been built on 11.1, not on 11.0 (I just tested it with csync2 which I know fails). Packages there may fail to run on 11.0, but there is no clear indication, just random failures at runtime. Maybe we'd need specific 11.0, 11.1, 11.2 releases instead of quarterly releases? Ari -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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"
ABI changes within stable branch
Now that we are on a faster upgrade policy for minor branches, it is expected that we'll upgrade from 11.0 to 11.1 to 11.2 much faster than in the old days. I can cope with that, but it appears that functional changes are also being made within the stable branch as seen here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=221672 A new fdatasync() method is available in 11.1 but not in 11.0 which means that I now need to maintain separate ports trees for each minor update. I've never done this before, assuming (correctly for me until now) that all ports build on the latest minor release within the stable branch would work on older releases until I was ready to upgrade them. Is this instance a mistake or am I misunderstanding the new policy? If I need to treat each release within the stable branch as a whole new platform for ports, that means a bunch of extra testing and maintenance work for me. Cheers Ari -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: TSC timekeeping and cpu states
On 14/8/17 3:08PM, Kevin Oberman wrote: > Again, the documentation lags reality. The default was changed for 11.0. It > is still conservative. In ALMOST all cases, Cmax will yield the bast results. > However, on large systems with many cores, Cmax will trigger very poor > results, so the default is C2, just to be safe. > > As far as possible TSC impact, I think older processors had TSC issues when > not all cores ran with the same clock speed. That said, I am not remotely > expert on such issues, so don't take this too seriously. Thanks Kevin What does 'large' and 'many cores' mean here? Is 24 cores large or small? For a server do we ever want the CPU to enter states other than C1? Ari -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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"
TSC timekeeping and cpu states
I note that in FreeBSD 11, we now have this: # grep performance_cx_lowest /etc/defaults/rc.conf performance_cx_lowest="C2" # Online CPU idle state However this wiki page suggests that C1 is the default https://wiki.freebsd.org/TuningPowerConsumption Are these inconsistent? I went looking for this because I've been having trouble with the TSC-low timecounter hardware choice and my system clock running at about 80% of normal speed. Moving to ACPI-fast solved this problem. Could the power saving CPU states be related to this problem, or should I look elsewhere for the TSC issue? This is a server, not a laptop. Thanks Ari -- ------> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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 forcing failover
My experience is that it doesn't cause them all the failover, even though an interface going down does cause them all to failover with the pre-emption feature enabled. Ari On 1/3/17 2:31pm, Freddie Cash wrote: > Doesn't "ifconfig vhid XX state master" do what you want? It forces that vhid > over to master, which should preempt the other interfaces to switch as well. > > One command. > > On Feb 28, 2017 5:10 PM, "Aristedes Maniatis" <mailto:a...@ish.com.au>> wrote: > > Yes, the automatic failover is great and works perfectly to bring all > interfaces over at once. But to manually force a failover I need to change > the advskew one interface at a time with ifconfig. > > Ari > > > On 1/3/17 12:04pm, Freddie Cash wrote: > > Do you have the preemption sysctl enabled? That will fail-over all carp > interfaces when any one fails. > > > > "sysctl -a | grep carp" > > > > I'm pretty sure there's also an ifconfig command to force the state as > either master or backup. Check the man page. > > > > > > On Feb 28, 2017 5:01 PM, "Aristedes Maniatis" <mailto:a...@ish.com.au> <mailto:a...@ish.com.au <mailto:a...@ish.com.au>>> > wrote: > > > > I have a pair network gateway boxes running FreeBSD 11 and pf. > Upstream runs VRRP to provide redundant links, one to each gateway. > Internally I'm using CARP for failover. > > > > All works well, but I find that manually failing over the link is a > bit complicated. In short I have this: > > > > em0: flags=8943 > metric 0 mtu 1500 > > media: Ethernet autoselect (100baseTX ) > > status: active > > carp: BACKUP vhid 1 advbase 1 advskew 50 > > igb0: flags=8943 > metric 0 mtu 1500 > > media: Ethernet autoselect (1000baseT ) > > status: active > > carp: BACKUP vhid 2 advbase 1 advskew 50 > > igb0.2: flags=8943 > metric 0 mtu 1500 > > status: active > > vlan: 2 vlanpcp: 0 parent interface: igb0 > > carp: BACKUP vhid 3 advbase 1 advskew 50 > > groups: vlan > > > > That's two internal vlans and one external network. Each interface > has its own vhid since that's the advice I had in the past. > > > > Now, what command can I type that I could run remotely (SSH over > the em0 link) to force all the CARP addresses simultaneously to decrease the > advskew and become MASTER. Alternatively I could run something on the MASTER > to make it BACKUP. Everything I've done so far is one command per interface > which has got me in trouble before as I manage to accidentally remove my own > access to the box before I'm done. > > > > Cheers > > Ari > > > > please cc me. > > > > -- > > ------> > > Aristedes Maniatis > > CEO, ish > > https://www.ish.com.au > > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > > > > -- > --> > Aristedes Maniatis > CEO, ish > https://www.ish.com.au > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
Re: CARP forcing failover
Yes, the automatic failover is great and works perfectly to bring all interfaces over at once. But to manually force a failover I need to change the advskew one interface at a time with ifconfig. Ari On 1/3/17 12:04pm, Freddie Cash wrote: > Do you have the preemption sysctl enabled? That will fail-over all carp > interfaces when any one fails. > > "sysctl -a | grep carp" > > I'm pretty sure there's also an ifconfig command to force the state as either > master or backup. Check the man page. > > > On Feb 28, 2017 5:01 PM, "Aristedes Maniatis" <mailto:a...@ish.com.au>> wrote: > > I have a pair network gateway boxes running FreeBSD 11 and pf. Upstream > runs VRRP to provide redundant links, one to each gateway. Internally I'm > using CARP for failover. > > All works well, but I find that manually failing over the link is a bit > complicated. In short I have this: > > em0: flags=8943 metric 0 > mtu 1500 > media: Ethernet autoselect (100baseTX ) > status: active > carp: BACKUP vhid 1 advbase 1 advskew 50 > igb0: flags=8943 metric 0 > mtu 1500 > media: Ethernet autoselect (1000baseT ) > status: active > carp: BACKUP vhid 2 advbase 1 advskew 50 > igb0.2: flags=8943 metric > 0 mtu 1500 > status: active > vlan: 2 vlanpcp: 0 parent interface: igb0 > carp: BACKUP vhid 3 advbase 1 advskew 50 > groups: vlan > > That's two internal vlans and one external network. Each interface has > its own vhid since that's the advice I had in the past. > > Now, what command can I type that I could run remotely (SSH over the em0 > link) to force all the CARP addresses simultaneously to decrease the advskew > and become MASTER. Alternatively I could run something on the MASTER to make > it BACKUP. Everything I've done so far is one command per interface which has > got me in trouble before as I manage to accidentally remove my own access to > the box before I'm done. > > Cheers > Ari > > please cc me. > > -- > --> > Aristedes Maniatis > CEO, ish > https://www.ish.com.au > GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A > -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
CARP forcing failover
I have a pair network gateway boxes running FreeBSD 11 and pf. Upstream runs VRRP to provide redundant links, one to each gateway. Internally I'm using CARP for failover. All works well, but I find that manually failing over the link is a bit complicated. In short I have this: em0: flags=8943 metric 0 mtu 1500 media: Ethernet autoselect (100baseTX ) status: active carp: BACKUP vhid 1 advbase 1 advskew 50 igb0: flags=8943 metric 0 mtu 1500 media: Ethernet autoselect (1000baseT ) status: active carp: BACKUP vhid 2 advbase 1 advskew 50 igb0.2: flags=8943 metric 0 mtu 1500 status: active vlan: 2 vlanpcp: 0 parent interface: igb0 carp: BACKUP vhid 3 advbase 1 advskew 50 groups: vlan That's two internal vlans and one external network. Each interface has its own vhid since that's the advice I had in the past. Now, what command can I type that I could run remotely (SSH over the em0 link) to force all the CARP addresses simultaneously to decrease the advskew and become MASTER. Alternatively I could run something on the MASTER to make it BACKUP. Everything I've done so far is one command per interface which has got me in trouble before as I manage to accidentally remove my own access to the box before I'm done. Cheers Ari please cc me. -- ------> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
Re: Boot partition size
On 30/1/17 2:20pm, Freddie Cash wrote: > And, you may be able to do that on the existing disks, as ZFS now leaves a MB > or two of "slack space" at the end of the device used in the vdev. This > allows for using drives/partitions that are the same size in MB but have > different numbers of sectors. This was an issue on the early ZFS days. > > So, you may be able to resize the freebsd-zfs partition by a handful of KB > without actually changing the size of the vdev. Brilliant, thank you. That worked a treat with a new boot size of 256k. Note that this page: https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror needs to be adjusted. This line: gpart add -b 34 -s 128k -t freebsd-boot ad0 needs to instead be gpart add -a 4k -s 512k -t freebsd-boot ad0 I don't have edit rights. Probably someone needs to clean up and merge many of these pages: https://wiki.freebsd.org/RootOnZFS/ Ari -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
Re: Boot partition size
Thanks for your reply Warner,
On 29/1/17 3:50pm, Warner Losh wrote:
> Unless you are running on tiny disks, you should use 512kB for maximum
> future proofing. Given the bloat that's happened in boot1/boot2 over
> the years, this is the only sensible default.
Then you ('you' in the very generic FreeBSD committers with permission sense)
should get the wiki changed (link in my previous email) to give better advice.
The advice of 128kB seems bad. More people will be hurt.
>> 2. Is there any possible short term future where ZFS volumes can be shrunk,
>> or will I be replacing every hard disk (or rebuilding the machine from
>> scratch)?
> Not easily. However, there's several options available to you: (1) not
> upgrading the boot partition
That seems contrary to the advice that zpool provides when you upgrade a pool.
It specifically tells you that it is really important to upgrade the boot
partition. But it doesn't tell you this is impossible due to space requirements
*before* you upgrade the pool.
Is your suggestion to continue upgrading the OS, but never upgrade the pool?
> (2) shrinking a swap partition to snag
> some space
Yes, except I put my swap into a zvol. I did this when I lost a disk once with
a dedicated swap partition and that caused the system to crash. So I realised
that dedicated swap was a really bad idea and I needed to choose between zvol
and gmirror. I chose zvol to avoid having one more thing to check and worry
about.
> (3) putting a larger boot partition at the 'end' of the
> disk where there's usually runt sectors due to how gpart (bogusly
> imho, but I've not been successful at advocating this viewpoint)
> rounds. There's up to an entire cylinder at the end (though LBAs make
> CHS bogus), which might be useful. It's also possible to move the
> start of the boot partition to a smaller LBA, which gives us more than
> the 44k we currently have. We may also be able to write a smaller GPT
> area if we use only a couple of partitions on the disk.
I read that the boot partition had to be the first partition on disk. Is that
wrong?
> In this case, there's no compelling
> reason to upgrade the boot blocks that I can see... A quick look at
> freebsd-update shows no calls to gpart or dd, which is necessary to
> change them.
But if we are using new ZFS code, and we upgrade the zpool, might that not
require new boot code to be able to boot the system?
I've already got one system I upgraded to FreeBSD 11, upgraded the pool once
everything looked good, and now I cannot upgrade the boot code. I don't want to
restart the machine... ever. That's possibly unrealistic, although I could boot
from USB in an emergency I guess.
Ari Maniatis
--
-->
Aristedes Maniatis
CEO, ish
https://www.ish.com.au
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
signature.asc
Description: OpenPGP digital signature
Boot partition size
As recently as last October, the best official advice was to make a 64kB boot partition. https://wiki.freebsd.org/action/diff/RootOnZFS/GPTZFSBoot/Mirror?action=diff&rev1=16&rev2=17 Now that turns out to be absolutely terrible advice and some people (like me) have dozens of machines that will never be upgradable to FreeBSD 11 or higher. It looks like there is no reasonable method of upgrade that doesn't involve replacing every hard disk on every machine (that's hundred of disks) with larger models. I use a zvol for swap, so I can't make swap smaller to solve the problem. I started with FreeBSD 4.1 and in 16 years... sigh... The ashift pain some years ago was also caused by FreeBSD default recommendations and settings not anticipating future needs quickly enough. But this mess now is completely self-inflicted foot shooting. 1. Why is the recommendation now 128kB and not much much higher? When that limit is broken in a couple of years, will there be another round of annoyed users? Is someone concerned that ZFS users are running hard disks over under 500Mb and need to save space? Surely the recommendation should be 512kB? 2. Is there any possible short term future where ZFS volumes can be shrunk, or will I be replacing every hard disk (or rebuilding the machine from scratch)? 3. Is there any possibility of getting a gptzfsboot which is 64kB but missing certain features I might not need? eg. a RAIDZ2 version that skips support for RAIDZ3 4. Will support be added to freebsd-update to warn users BEFORE they try to upgrade and kill their system? Please cc me, I'm not subscribed. Ari Maniatis -- --> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
mariadb/percona cluster choices
Does anyone have recommendations or experience migrating away from MySQL toward either MariaDB or Percona? I'm not looking for a discussion about the products themselves; there is plenty on the internet to read about that. But I'm interested in stability and support on FreeBSD. None of mysql, percona or mariadb have anything but a fleeting reference to FreeBSD on their sites. And the FreeBSD ports appear to have a roughly equal set of patches [1] [2] [3], so it doesn't appear that any of them have upstreamed patches or perform their own testing on FreeBSD. I'm looking to adopt Galera for clustering. Is there anything to recommend one over the other with regard to stability on BSD? Do either of Maria or Percona have a stronger involvement with the FreeBSD community? I know Oracle isn't big on community :-( Cheers Ari [1] https://reviews.freebsd.org/diffusion/P/browse/head/databases/mysql57-server/files/ [2] https://reviews.freebsd.org/diffusion/P/browse/head/databases/percona56-server/files/ [3] https://reviews.freebsd.org/diffusion/P/browse/head/databases/mariadb101-server/files/ -- ------> Aristedes Maniatis CEO, ish https://www.ish.com.au GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
Re: freebsd-update incorrect hashes
On 24/12/2015 12:22am, rai...@ultra-secure.de wrote: > Am 2015-12-23 13:25, schrieb Aristedes Maniatis: >> I've had problems with freebsd-update for many years now. It is by far >> the least reliable component of FreeBSD since I started with the >> operating system back at 3.4 in 1999. >> >> Anyhow, I'm usually able to get past the exceedingly slow downloads >> and errors to the upgrade process, but this time nothing I do will get >> me to the end. I've tried deleting /var/db/freebsd-update but several >> hours later I was at the same place again. The internet link is fast, >> but with a web proxy in this location, some downloads are slightly >> delayed while the virus scanner on the proxy does its thing. Perhaps >> 3-5 seconds delayed. > > > > The problem is phttpget or the proxy, depending on the point of view. > > Some proxies have (had) problems with the pipelined http requests that > phttpget seems to use. > > apt (Debian/Ubuntu) has, too - but they can be disabled altogether there. > > http://webcache.googleusercontent.com/search?q=cache:OwcOVJamJOoJ:https://www.astaro.org/gateway-products/web-protection-web-filtering-application-visibility-control/55213-http-pipelining-broken-after-upgrade-utm-9-3-a.html+&cd=1&hl=de&ct=clnk&gl=ch > > IMO, there should be an option to use wget instead of phttpget. Or at least > disable the request-pipelining. > There was a PR with patches floating around to make freebsd-update use wget, > but it never gained traction. > > Also, didn't phttpget have problems with proxies needing authentication? > I usually have authentication at the proxy disabled for *.freebsd.org for > this reason. In my case, the proxy doesn't need authentication. But I can see from the code (I've just discovered that freebsd-update is in fact a shell script) that if it fails, then on the next run it starts again from the beginning. No downloaded files are moved into the files folder until they all succeed. I've found debug mode, and what it is doing is downloading every single file (1800 of them in my case) and then only at the end checking to see if the hashes are right. When it fails, it just stops and I need to start again. Each run takes about 40 minutes. Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
freebsd-update incorrect hashes
I've had problems with freebsd-update for many years now. It is by far the least reliable component of FreeBSD since I started with the operating system back at 3.4 in 1999. Anyhow, I'm usually able to get past the exceedingly slow downloads and errors to the upgrade process, but this time nothing I do will get me to the end. I've tried deleting /var/db/freebsd-update but several hours later I was at the same place again. The internet link is fast, but with a web proxy in this location, some downloads are slightly delayed while the virus scanner on the proxy does its thing. Perhaps 3-5 seconds delayed. I've run the update maybe a dozen times, progressing a few patches each time. But it will always fetch 64 patches and then the number of files to fetch will drop by 5-25 # freebsd-update upgrade -r 10.2 -s update.freebsd.org Looking up update.freebsd.org mirrors... 4 mirrors found. Fetching metadata signature for 9.3-RELEASE from update6.freebsd.org... done. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... done. Inspecting system... done. The following components of FreeBSD seem to be installed: kernel/generic world/base world/doc world/lib32 The following components of FreeBSD do not seem to be installed: world/games Does this look reasonable (y/n)? y Fetching metadata signature for 10.2-RELEASE from update6.freebsd.org... done. Fetching metadata index... done. Fetching 1 metadata patches. done. Applying metadata patches... done. Fetching 1 metadata files... done. Inspecting system... done. Fetching files from 9.3-RELEASE for merging... done. Preparing to download files... done. Fetching 64 patches.102030405060.. done. Applying patches... done. Fetching 1834 files... 109e9b1e3e8719aa81bc06e4c4c8dc642db7137ea8330f11f70b8e91524afef7 has incorrect hash. Different file each time with an incorrect hash. So it will make very slow progress. Oddly, it had no issue downloading the 10,000 patches it needed, except for the last 64. No idea why it downloads them again and again each time I attempt this. Are there any ways to manually dump the right files in the right place? When I run phttpget by hand, I have no trouble very quickly downloading the files it seems to want. But how do I trick the system into skipping downloading them again? phttpget has no man pages, so I've been unable to get it to spit out any more verbose options. Thanks Ari -- ------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
Re: trouble upgrade jails to 10.2 (make distrib-dirs)
On 15/11/2015 12:14am, Miroslav Lachman wrote: >> I am getting a failure running mergemaster as per the FreeBSD handbook. I'm >> a bit lost as to what the error is telling me to do. > > What was the method used to upgrade host system and jail? Did you used > freebsd-update or make installworld? freebsd-update from 10.1 to 10.2. Ari -- ------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
trouble upgrade jails to 10.2 (make distrib-dirs)
I am getting a failure running mergemaster as per the FreeBSD handbook. I'm a bit lost as to what the error is telling me to do. Thanks for any help Ari # mergemaster -U -D /jails/anu_6002 realpath: /usr/src: No such file or directory *** The directory specified for the temporary root environment, /var/tmp/temproot, exists. This can be a security risk if untrusted users have access to the system. Use 'd' to delete the old /var/tmp/temproot and continue Use 't' to select a new temporary root directory Use 'e' to exit mergemaster Default is to use /var/tmp/temproot as is How should I deal with this? [Use the existing /var/tmp/temproot] d *** Deleting the old /var/tmp/temproot *** Creating the temporary root environment in /var/tmp/temproot *** /var/tmp/temproot ready for use *** Creating and populating directory structure in /var/tmp/temproot make: don't know how to make distrib-dirs. Stop make: don't know how to make distrib-dirs. Stop *** FATAL ERROR: Cannot 'cd' to and install files to the temproot environment -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A signature.asc Description: OpenPGP digital signature
merging commiter headers
I've just upgraded three machines from 10.1 to 10.2. Congratulations on the release... This was one of the worst upgrade experiences in my FreeBSD history, going back to 4.0 days. I used freebsd-update but I was absolutely swamped with merging the svn (nee cvs) headers in roughly 80 files. <<<<<<< current version # $FreeBSD: release/10.0.0/etc/periodic/security/800.loginfail 254974 2013-08-27 21:20:28Z jlh $ === # $FreeBSD: releng/10.2/etc/periodic/security/800.loginfail 263661 2014-03-23 12:58:48Z brueffer $ >>>>>>> 10.2-RELEASE Let's leave aside why users would care what commit number, date or user last touched this file. Let's assume that you don't need a header to tell you the path of the file you are looking at. And let's leave aside why release is now releng (are we saving bytes?). And let's leave aside why the diff shows an upgrade from 10.0 to 10.2 when actually this was from 10.1 to 10.2. Can't some merge tool inside freebsd-update just sort this out for me? Please? Not only does it take over 45 minutes to go through all those files, but I feel sure I missed something. Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: release documentation confusing for 9.1
Kevin Oberman wrote: On Tue, Jul 31, 2012 at 5:52 PM, Aristedes Maniatis wrote: Could I ask that someone with appropriate access rights review the state of release documentation for 9.1 beta. It is very confused. 1. This page is the best information available: http://www.freebsd.org/releases/9.1R/schedule.html 2. The link from the front page ( http://www.freebsd.org/ ) is labelled "Upcoming: 9.1-BETA1" but goes to a page which is mostly about existing releases, not the next release. http://www.freebsd.org/where.html#helptest 3. Clicking on the "view" link for the 9.1 information on that page takes you to http://wiki.freebsd.org/Releng/9.1TODO which looks a lot like the information in point [1] but wrong/old. 4. On http://www.freebsd.org/where.html#helptest there is a link to "FreeBSD Snapshot Releases" for people interested in "FreeBSD-CURRENT (AKA 10.0-CURRENT)". But following the link takes you to a page where you get linked to "9-CURRENT, 8-STABLE, 7-STABLE, and 6-STABLE" snapshots. It is possible I'm just stuck in the past, but I've never been able to navigate the 'new' bowling ball branded FreeBSD site nearly as well as the older incarnation. And yes, I can eventually figure it all out... but this information could be a whole lot clearer. I design information presentation for a living, so perhaps I'm picky about these things, but I do think that confusion could turn people away from my favourite operating system. I'm happy to help if someone wants to enlist my assistance, but I don't currently have any commit rights on this project. RE has not done very well in updating this stuff for several releases. RE is a very hard job and I understand that they are busy with both 9.1 and $REAL_JOB. I'd love for them to find someone whom they trust and with reasonable clue to whom they could give the right to update all of this stuff. It would still lag a bit, but it would be closer. As far as what will be in 9.1, the doc tree was tagged for 9.1 two days ago and can be downloaded from svn or cvs and built. Note that it's all in sgml and you need to build the various formats. I'm not sure when they will hit the web site and, of course, noting is official until the release, but it is unlikely to change at this point except for minor corrections. Thanks Kevin I think that perhaps the first job (when everyone isn't busy with releasing) is to examine the relationship between the wiki and the website, make sure everything is well organised, and make sure it is trivial to update by the release people. Beyond that, the actual structure of pages within the website doesn't make sense (to me) and isn't particularly clear from the home page. Analysis of web logs might give some insight to what people are looking for and viewing on the freebsd site (although of course, doesn't tell you what they are just unable to find despite searching for it). Over at Apache, the infra people have moved our project websites to a svn pubsub approach which works well with the established user base of developers who know svn. Updating pages becomes fairly trivial and a web rich text editor interface means it is even easy if you are away from your regular toolset. Whatever the process, it has to be easy enough that RE can fit it into their workflow without additional burden. Ideally, scripts could detect the release tags in svn and update the website automatically. Cheers Ari ___ 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"
release documentation confusing for 9.1
Could I ask that someone with appropriate access rights review the state of release documentation for 9.1 beta. It is very confused. 1. This page is the best information available: http://www.freebsd.org/releases/9.1R/schedule.html 2. The link from the front page ( http://www.freebsd.org/ ) is labelled "Upcoming: 9.1-BETA1" but goes to a page which is mostly about existing releases, not the next release. http://www.freebsd.org/where.html#helptest 3. Clicking on the "view" link for the 9.1 information on that page takes you to http://wiki.freebsd.org/Releng/9.1TODO which looks a lot like the information in point [1] but wrong/old. 4. On http://www.freebsd.org/where.html#helptest there is a link to "FreeBSD Snapshot Releases" for people interested in "FreeBSD-CURRENT (AKA 10.0-CURRENT)". But following the link takes you to a page where you get linked to "9-CURRENT, 8-STABLE, 7-STABLE, and 6-STABLE" snapshots. It is possible I'm just stuck in the past, but I've never been able to navigate the 'new' bowling ball branded FreeBSD site nearly as well as the older incarnation. And yes, I can eventually figure it all out... but this information could be a whole lot clearer. I design information presentation for a living, so perhaps I'm picky about these things, but I do think that confusion could turn people away from my favourite operating system. I'm happy to help if someone wants to enlist my assistance, but I don't currently have any commit rights on this project. Cheers Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: missing 9.0 installation packages
On 26/01/12 3:48 AM, John Baldwin wrote: On Monday, January 23, 2012 4:27:26 am Aristedes Maniatis wrote: I wanted to install src onto an existing RELEASE-9.0 box (that is maintained using freebsd-update), since I needed to build lsof. I then used sysintall as follows: * Media: ftp.freebsd.org * Distribution: custom -> src -> sys/base/include/lib Error message was then: | Unable to transfer the sbase distribution from │ │ ftp://ftp.freebsd.org. │ ││ │ Do you want to try to retrieve it again? | I see some distributions here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/9.0-RELEASE/ but I can't see anything called sbase.txz in my searching. This might work fine from CD, but this server is in the colo without an easy way for me to insert a CD. You can't use sysinstall on 9.0 since the distribution format changed. I don't think there is a way to install them via bsdinstall post-install. (Nathan cc'd in case there is). I think you can root around in the FTP directory and find the source tarball and untar it on your box by hand however. Thanks for this information. I guess we are in an interim place between sysinstall and the new installer. Perhaps, in 9.1, freebsd-update should remove sysinstall since it not longer works properly. Perhaps this functionality could be built into freebsd-update? After all, it scans the system to find which packages have been installed and which have not. Wouldn't it be nice if it could go one step further and install them for you? Right now, if freebsd-update gets stuck (for example, because you have a custom kernel) it is quite hard to get it unstuck and get back on the binary update path. Thanks for the very nice work in 9.0. Subjectively, the disk subsystem changes from 8.2 to 9.0 have been a huge performance improvement. Cheers Ari -- ------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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"
missing 9.0 installation packages
I wanted to install src onto an existing RELEASE-9.0 box (that is maintained using freebsd-update), since I needed to build lsof. I then used sysintall as follows: * Media: ftp.freebsd.org * Distribution: custom -> src -> sys/base/include/lib Error message was then: | Unable to transfer the sbase distribution from │ │ ftp://ftp.freebsd.org. │ ││ │ Do you want to try to retrieve it again? | I see some distributions here: ftp://ftp.freebsd.org/pub/FreeBSD/releases/amd64/amd64/9.0-RELEASE/ but I can't see anything called sbase.txz in my searching. This might work fine from CD, but this server is in the colo without an easy way for me to insert a CD. Cheers Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: dumpdev default
On 18/01/12 2:07 AM, Ken Smith wrote: On Tue, 2012-01-17 at 18:37 +1100, Aristedes Maniatis wrote: The manual states that dumpdev "AUTO is the default as of FreeBSD 6.0" [1] However: # uname -a FreeBSD xx 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # grep dumpdev /etc/defaults/rc.conf dumpdev="NO" # Device to crashdump to (device name, AUTO, or NO). savecore_flags="" # Used if dumpdev is enabled above, and present. It looks like NO is still the default. Is there a reason why this should not be turned on even for production machines? I haven't read about any side effects, but it seems to be off by default for some reason. Please cc me on any responses since I'm not currently subscribed. Cheers Ari If you use bsdinstall(8) to install a machine from scratch it explicitly asks you about whether you want crash dumps enabled or not. As long as you're aware that the crash dumps are happening and know that you might need to clean up after them (remove stuff from /var, etc) there are no dangers. You just need to make sure wherever the crash dumps will wind up going (/var by default) has enough space to handle both the crash dumps and anything else the machines need to do. We currently have no provision for preventing crash dumps from filling up the target partition. I keep advocating for the conservative side of this issue, preferring that crash dumps be an opt-in setting until we have infrastructure in place to prevent them from filling the target partition. I still picture there being people out there who don't know what crash dumps are, wouldn't know they might need to clean up after them, and may be negatively impacted if the target partition wound up full without them knowing why. Thanks Ken. That is very clear. If you have time, please update the documentation with that answer too since others are likely to be confused by what I found there which is incorrect and incomplete. Also, for ZFS users, I assume that the first swap disk will be default? So this is another consideration when sizing up swap partitions as compared to the size of memory installed. Thanks Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: dumpdev default
On 17/01/12 7:10 PM, Jeremy Chadwick wrote: On Tue, Jan 17, 2012 at 06:37:34PM +1100, Aristedes Maniatis wrote: The manual states that dumpdev "AUTO is the default as of FreeBSD 6.0" [1] However: # uname -a FreeBSD xx 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # grep dumpdev /etc/defaults/rc.conf dumpdev="NO" # Device to crashdump to (device name, AUTO, or NO). savecore_flags="" # Used if dumpdev is enabled above, and present. It looks like NO is still the default. Is there a reason why this should not be turned on even for production machines? I haven't read about any side effects, but it seems to be off by default for some reason. The Handbook is incorrect, and I filed a PR for this matter last year (PR 159650): http://lists.freebsd.org/pipermail/freebsd-doc/2011-August/018654.html Worth reading: http://lists.freebsd.org/pipermail/freebsd-stable/2011-August/063541.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-August/063542.html http://lists.freebsd.org/pipermail/freebsd-stable/2011-August/063543.html And the entire thread: http://lists.freebsd.org/pipermail/freebsd-stable/2011-August/063535.html Ahh!!! Someone give Jeremy a commit bit for the FreeBSD documentation already! The commit you reference by mnag has only the following log: -- - Change dumpdev default to "NO". Only HEAD is set to "AUTO" Discussed with: re Approved by:re (scottl) -- Not enough to know whether dumpdev is now considered a dangerous feature for production servers. Only scottl or mnag may know the answer. I've also found another bug. man dumpon(8) shows: The dumpon utility will refuse to enable a dump device which is smaller than the total amount of physical memory as reported by the hw.physmem sysctl(8) variable. However, I have found that # dumpon -v /dev/ad4s1b kernel dumps on /dev/ad4s1b # sysctl hw.physmem hw.physmem: 25744310272 # swapinfo Device 1K-blocks UsedAvail Capacity /dev/ad4s1b 83886080 8388608 0% So, 24Gb RAM, 8Gb swap device. No complaints from dumpon. Either it is silently failing (poor response from the app) or it is incorrectly setting the dump device to something too small. Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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"
dumpdev default
The manual states that dumpdev "AUTO is the default as of FreeBSD 6.0" [1] However: # uname -a FreeBSD xx 9.0-RELEASE FreeBSD 9.0-RELEASE #0: Tue Jan 3 07:46:30 UTC 2012 r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 # grep dumpdev /etc/defaults/rc.conf dumpdev="NO" # Device to crashdump to (device name, AUTO, or NO). savecore_flags="" # Used if dumpdev is enabled above, and present. It looks like NO is still the default. Is there a reason why this should not be turned on even for production machines? I haven't read about any side effects, but it seems to be off by default for some reason. Please cc me on any responses since I'm not currently subscribed. Cheers Ari [1] http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: freebsd-update problems
On 7/01/12 9:17 PM, Gianni Vialetto wrote: 2012/1/7 Aristedes Maniatis: [...] 1. I am clearly running 8.2-p5, but the final message says "no updates needed". That's clearly not correct since p5< p8. And running uname again after this results in still seeing p5. That's not really true. Unless an update upgrades the kernel, the result of "uname -a" will not change. For it to change, you have to recompile the kernel yourself - using the generic of a custom configuration. Your current release level is the fourth field in /var/db/freebsd-update/tag, IIRC. Thanks for that clarification. That is a very obscure place to look, but it appears to be correct. I had never noticed before the difference between kernel patch level (in uname) and overall system patch level. Many years ago I used to upgrade FreeBSD by compiling kernel and world every time, so I guess those things used to match. But binary updating is so much faster these days and the benefits of optimising the kernel with only the things I need are fairly negligible. If I could make a suggestion for freebsd-update. When it runs, it might spit out this: Current system: -- running kernel 8.1-RELEASE-p4 -- installed kernel 8.1-RELEASE-p5 (will be running after reboot) -- intalled system 8.1-RELEASE-p8 The second line would be conditionally output only if it differs from the first line. And of course, some suggestion about how to resolve the modified locally files would be ideal. Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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-update problems
Freebsd-update is both an excellent tool, but also sadly lacking in some ways, mostly documentation. Let's look at a recent experience... - # uname -a FreeBSD splash.internal 8.1-RELEASE-p5 FreeBSD 8.1-RELEASE-p5 #0: Tue Sep 27 16:49:00 UTC 2011 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 # freebsd-update fetch Looking up update.FreeBSD.org mirrors... 4 mirrors found. Fetching metadata signature for 8.1-RELEASE from update5.FreeBSD.org... done. Fetching metadata index... done. Inspecting system... done. Preparing to download files... done. The following files are affected by updates, but no changes have been downloaded because the files have been modified locally: /var/db/mergemaster.mtree No updates needed to update system to 8.1-RELEASE-p8. - Some problems: 1. I am clearly running 8.2-p5, but the final message says "no updates needed". That's clearly not correct since p5 < p8. And running uname again after this results in still seeing p5. My guess is that the message should say: No update will be applied until you merge the locally modified files, OR Or else, freebsd-update is just broken and refuses to update the system properly for an unknown reason. 2. I didn't touch mergemaster.mtree manually. Well, I don't think I did. But even if I had, could the tool give me some clue as to how to proceed from here? Do I now have to go back to csup to update my system and never be able to use freebsd-update again? Is there a trick to fool freebsd-update into overwriting this file which I don't think I touched? It would be nice if freebsd-update could be more helpful about what the user should do next when it finds an error. Thanks Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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"
system internal timer runs 10 times too slow
We upgraded an existing system to a new motherboard/CPU and found that timing in various programs is very odd. For example "top" only updates every 10 seconds instead of every second. And this confirms the oddness: # while true; do echo `date`; sleep 1; done Thu Jul 7 19:09:01 EST 2011 Thu Jul 7 19:09:11 EST 2011 Thu Jul 7 19:09:21 EST 2011 10 seconds instead of 1. So I looked first at the kernel timers: # dmesg | grep -i time Timecounter "i8254" frequency 1193182 Hz quality 0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 pci3: at device 0.1 (no driver attached) atrtc0: port 0x70-0x71 irq 8 on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 Timecounters tick every 1.000 msec I switched i8254 and then to HPET. No difference. # sysctl -w kern.timecounter.hardware=i8254 kern.timecounter.hardware: ACPI-fast -> i8254 # while true; do echo `date`; sleep 1; done Thu Jul 7 19:09:40 EST 2011 Thu Jul 7 19:09:41 EST 2011 I switched to TSC: # sysctl -w kern.timecounter.hardware=TSC kern.timecounter.hardware: HPET -> TSC # while true; do echo `date`; sleep 1; done Thu Jul 7 19:25:56 EST 2011 Thu Jul 7 19:25:57 EST 2011 Thu Jul 7 19:25:58 EST 2011 Now this looks like it fixed the problem, but actually it is worse. Now the clock matches what you'd expect, but there is still 10 seconds in real time between those date entries. That is, now the system clock is running 10 times too slow as well. # uname -a FreeBSD delish.ish.com.au 8.2-RELEASE FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 Base board information Manufacturer: ASUSTeK Computer INC. Product Name: P6X58D-E BIOS information Vendor: American Megatrends Inc. Version: 0502 Release Date: 11/16/2010 BIOS Revision: 8.15 CPU Model: Intel(R) Core(TM) i7 CPU 960 @ 3.20GHz Thanks in advance for any help. Ari -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: zpool upgrade, can't boot
On 5/05/11 7:24 PM, Aristedes Maniatis wrote: Not only do you have to get the boot loaders installed properly [1] but also there is a breakage in the FreeBSD 8.2-RELEASE code [2]. The MBR bootloader is broken in 8.2 and will not work with ZFS under at least some circumstances (2 of our boxes had the problem). The problem has been reported on the freebsd-fs list and I notice a fix has gone into svn for the 8-STABLE branch. You need to get a bootloader from 8-CURRENT or convert your partitions over to GPT if you hit that particular bug. But you aren't up to hitting that bug yet... you haven't installed the newer bootloader at the point you are up to. Ari [1] [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=153552 Sorry, [1] should be http://www.ish.com.au/node/1434 That has some useful pointers for installing the zfsboot onto MBR disks, but I'm sure you can find similar information in other places (just not in the FreeBSD handbooks unforuntately) Ari -- ------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: zpool upgrade, can't boot
On 3/05/11 2:42 AM, Jeff Blank wrote: Hi, I recently upgraded from 8.0-STABLE to 8.2-STABLE (Apr. 29 checkout) and upgraded my zpool (includes root FS) from v13 to v15. This is a dual-boot laptop, so I'm using MBR/boot0 and not GPT. Here's what happens when I boot: F1 Win F2 ? F3 FreeBSD F6 PXE Boot: F3 ZFS: unsupported ZFS version 15 (should be 13) No ZFS pools located, can't boot I've googled around, but I can't find anything relevant for MBR/boot0 configurations, just GPT. I've ensured that the loaders and boot0/boot1/boot2 are all new, and I rebuilt/reinstalled them in a fixit environment just to be sure. I also ran 'boot0cfg -B' (with an appropriate -b), but nothing has changed. How can I get my pool booting again? Not only do you have to get the boot loaders installed properly [1] but also there is a breakage in the FreeBSD 8.2-RELEASE code [2]. The MBR bootloader is broken in 8.2 and will not work with ZFS under at least some circumstances (2 of our boxes had the problem). The problem has been reported on the freebsd-fs list and I notice a fix has gone into svn for the 8-STABLE branch. You need to get a bootloader from 8-CURRENT or convert your partitions over to GPT if you hit that particular bug. But you aren't up to hitting that bug yet... you haven't installed the newer bootloader at the point you are up to. Ari [1] [2] http://www.freebsd.org/cgi/query-pr.cgi?pr=153552 -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: fault tolerant web servers on freebsd
On 7/04/10 5:00 PM, Andriy Gapon wrote: on 07/04/2010 09:05 Aristedes Maniatis said the following: Until we get to 'database' everything is HA and quite easy to build and manage. Having a clustered database solution is expensive and beyond most smallish budgets. mysql and postgresql don't have anything available that is quite ready yet (IMO), so you'll need to be talking to the bigger (expensive) players about their clustered offerings. Out of curiosity: have you considered MySQL Cluster: http://en.wikipedia.org/wiki/MySQL_Cluster http://www.mysql.com/products/database/cluster/faq.html If yes, can you share your evaluation results? Thanks! This is getting a bit offtopic to this list, but there are severe limitations with that product which make it unsuitable for my needs. Ari Maniatis -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: fault tolerant web servers on freebsd
On 6/04/10 7:10 AM, Maciej Jan Broniarz wrote: W dniu 10-04-05 22:43, jfar...@goldsword.com pisze: Quoting Maciej Jan Broniarz : W dniu 10-04-05 22:08, Tonix (Antonio Nati) pisze: Maciej Jan Broniarz ha scritto: W dniu 10-04-05 17:45, Mike Jakubik pisze: So first you have to define your workload, then define what errors you must avoid or allow, and then define how to deal with failures, errors, etc. Then you can start talking about High Availability vs. level of Fault tolerance, vs. Let's say i need to run a few php/sql based web sites and I would like to maintain uptime of about 99,99% per month. No matter how good the hardware - it will always fail at some time. My goal is to build a system, that can maintain that uptime. From what You say I need some level of HA system, to maintain the required uptime. So, as I've said earlier (correct me, if I'm wrong) - the setup could look something like that: - 2 web servers with carp - 2 storage servers with on-line sync mechanism running - 2 mysql servers with on-line database replication (i'm skiping power and network issues at the moment). Few people have told me about a setup with linux, drbd and heartbeat which offers them some level of HA. Has anyone tried anything similar on FreeBSD? We've recently set up a new colo facility with the following: * dual ethernet links from our upstream * dual HA pfSense (FreeBSD) boxes running haproxy to load balance incoming requests amongst live web servers * dual switches * 2 (or more) web (application) servers * database Until we get to 'database' everything is HA and quite easy to build and manage. Having a clustered database solution is expensive and beyond most smallish budgets. mysql and postgresql don't have anything available that is quite ready yet (IMO), so you'll need to be talking to the bigger (expensive) players about their clustered offerings. You need redundancy within the database application across multiple machines. Possible, but not easy. You aren't going to be doing that completely within the operating system itself. DRDB sort of gets you there, but DRDB isn't synchronous with the database activity, so you might still lose data. A cheaper option is to use master-slave replication (postgresql and mysql offer this) and CARP failover (just don't fail back!). But it hasn't been quite robust enough for my liking. Ari Maniatis -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On 29/03/10 7:04 PM, Doug Barton wrote: portmaster -r graphics/png That won't work, the man page clearly says that it has to be a port directory or glob pattern from /var/db/pkg. The "glob pattern" bit of that was (unfortunately) broken up till version 2.20, which I just committed. I'm confused. The manual actually says: [-R] -r name/glob of port in /var/db/pkg When I try your suggestion I get this: # portmaster -r png- ===>>> No valid installed port, or port directory given ===>>> Try portmaster --help And this doesn't work either: # portmaster -r graphics/png ===>>> No valid installed port, or port directory given ===>>> Try portmaster --help So, as you say the pkg pattern is broken, but also 'port directory' doesn't work either unlike your suggestions above. It would be nice for both pkg and directory patterns to be more consistently available, but in the meantime readers of UPDATING are going to be confused. Ari Maniatis -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On 29/03/10 1:15 PM, Garrett Cooper wrote: portmaster -r png- Is that correct? I haven't seen that notation before (although I might just have missed it in the docs). I would have used portmaster -r graphics/png Ari -- ------> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On 29/03/10 12:38 AM, Ion-Mihai Tetcu wrote: The first one was done, update of graphics/png (including a shared lib version bump), with about 5000 ports affected. The UPDATING entry for the png update looks very wrong. Wrong date, wrong text, wrong instructions for portmaster. 20090328: AFFECTS: users of graphics/png AUTHOR: din...@freebsd.org The png library has been updated to version 1.4.1. Please rebuild all ports that depend on it. If you use portmaster: portmaster -r jpeg- If you use portupgrade: portupgrade -fr graphics/jpeg -- --> Aristedes Maniatis ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: upgrade 7.2 to 8.0 problems
On 4/01/10 5:02 PM, Aristedes Maniatis wrote: # AMD64, Supermicro hardware. ZFS filesystem (booting to UFS, then rest of the file system /usr /var /tmp on ZFS). I used "freebsd-update upgrade -r 8.0-RELEASE" and all went well for the usual first install of the kernel with "freebsd-update install". After rebooting into single user mode, I manually mounted the ZFS partitions (which needs to be done as follows since the ZFS userland tools are incompatible with 8.0): mount -uw / mount -t zfs tank/usr /usr mount -t zfs tank/var /var mount -t zfs tank/tmp /tmp mount /bootdir Then I ran "freebsd-update install" for the second time to install the userland. The disk lights flashed a lot at the start, but then the system came to an almost complete halt. Looking at 'systat -vmstat' I can see that the disk and cpu are both almost idle. 'top' doesn't work (since it probably is the old userland). 'ps ax' shows that freebsd-install is running and has spawned an 'install' command. It is installing files at the rate of about one per 5 minutes. At this rate it should be done by next Christmas. I can see that the files it completes have their modified date changed to the current date. There is nothing interesting in /var/log/messages. It is still working, and I don't want to kill it for fear of ending up with a completely non-functional system. Any thoughts about this problem? I'm really stumped. Just for the archives... the problem was a non-functional LDAP. I had thought that in single user mode nsswitch was bypassed, but I was wrong and the (non-running) LDAP server was being queried for every 'install'. The timeout (5 minutes?) was the delay before it then proceeded to the next file. Ari Maniatis -- --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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"
upgrade 7.2 to 8.0 problems
# AMD64, Supermicro hardware. ZFS filesystem (booting to UFS, then rest of the file system /usr /var /tmp on ZFS). I used "freebsd-update upgrade -r 8.0-RELEASE" and all went well for the usual first install of the kernel with "freebsd-update install". After rebooting into single user mode, I manually mounted the ZFS partitions (which needs to be done as follows since the ZFS userland tools are incompatible with 8.0): mount -uw / mount -t zfs tank/usr /usr mount -t zfs tank/var /var mount -t zfs tank/tmp /tmp mount /bootdir Then I ran "freebsd-update install" for the second time to install the userland. The disk lights flashed a lot at the start, but then the system came to an almost complete halt. Looking at 'systat -vmstat' I can see that the disk and cpu are both almost idle. 'top' doesn't work (since it probably is the old userland). 'ps ax' shows that freebsd-install is running and has spawned an 'install' command. It is installing files at the rate of about one per 5 minutes. At this rate it should be done by next Christmas. I can see that the files it completes have their modified date changed to the current date. There is nothing interesting in /var/log/messages. It is still working, and I don't want to kill it for fear of ending up with a completely non-functional system. Any thoughts about this problem? I'm really stumped. Thanks Ari Maniatis -- --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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"
vnode_pager_putpages error
FreeBSD 7.2 amd64. Running Apache httpd application (MPM worker threads) and other applications. ZFS file system. After some weeks of uptime, we are seeing these errors repeated many times: vnode_pager_putpages: I/O error 69 vnode_pager_putpages: residual I/O 16384 at 0 After that, httpd dies. On another occasion the entire system rebooted and we are guessing the symptoms are the same, but the console was lost so we can't tell for sure. * Can sometime tell me where I found out what error 69 means? Is there something in the docs somewhere I can look at? * My uninformed guess is that this is some sort of swap/memory exhaustion. Could it be a memory leak in httpd (or one of its modules)? Or could ZFS memory exhaustion be the issue here? If so, we'd probably move to 8.0 as soon as possible with all its ZFS improvements. Any clues to tracking this down would be appreciated. It is a production server and doesn't happen often enough to easily reproduce. Thanks Ari Maniatis -- --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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"
pcpu.h kernel crash with 7.2
This is a FreeBSD 7.2 machine in production. I'm not an expert at debugging kernel problems, but I've still got the vmcore if there is anything else I should run on it to extract more information. Thanks Ari Maniatis # uname -a FreeBSD dash.internal 7.2-RELEASE-p2 FreeBSD 7.2-RELEASE-p2 #0: Wed Jun 24 00:14:35 UTC 2009 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64 #kgdb /boot/kernel/kernel /var/crash/vmcore.3 GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-marcel-freebsd"... Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 4; apic id = 04 fault virtual address = 0x11 fault code = supervisor read data, page not present instruction pointer = 0x8:0x804fbec9 stack pointer = 0x10:0x7b6a2830 frame pointer = 0x10:0x1 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 69329 (httpd) trap number = 12 panic: page fault cpuid = 4 Uptime: 34d3h21m46s Physical memory: 24561 MB Dumping 5146 MB: 5131 5115 5099 5083 5067 5051 5035 5019 5003 4987 4971 4955 4939 4923 4907 4891 4875 4859 4843 4827 4811 4795 4779 4763 4747 4731 4715 4699 4683 4667 4651 4635 4619 4603 4587 4571 4555 4539 4523 4507 4491 4475 4459 4443 4427 4411 4395 4379 4363 4347 4331 4315 4299 4283 4267 4251 4235 4219 4203 4187 4171 4155 4139 4123 4107 4091 4075 4059 4043 4027 4011 3995 3979 3963 3947 3931 3915 3899 3883 3867 3851 3835 3819 3803 3787 3771 3755 3739 3723 3707 3691 3675 3659 3643 3627 3611 3595 3579 3563 3547 3531 3515 3499 3483 3467 3451 3435 3419 3403 3387 3371 3355 3339 3323 3307 3291 3275 3259 3243 3227 3211 3195 3179 3163 3147 3131 3115 3099 3083 3067 3051 3035 3019 3003 2987 2971 2955 2939 2923 2907 2891 2875 2859 2843 2827 2811 2795 2779 2763 2747 2731 2715 2699 2683 2667 2651 2635 2619 2603 2587 2571 2555 2539 2523 2507 2491 2475 2459 2443 2427 2411 2395 2379 2363 2347 2331 2315 2299 2283 2267 2251 2235 2219 2203 2187 2171 2155 2139 2123 2107 2091 2075 2059 2043 202 7 2011 1995 1979 1963 1947 1931 1915 1899 1883 1867 1851 1835 1819 1803 1787 1771 1755 1739 1723 1707 1691 1675 1659 1643 1627 1611 1595 1579 1563 1547 1531 1515 1499 1483 1467 1451 1435 1419 1403 1387 1371 1355 1339 1323 1307 1291 1275 1259 1243 1227 1211 1195 1179 1163 1147 1131 1115 1099 1083 1067 1051 1035 1019 1003 987 971 955 939 923 907 891 875 859 843 827 811 795 779 763 747 731 715 699 683 667 651 635 619 603 587 571 555 539 523 507 491 475 459 443 427 411 395 379 363 347 331 315 299 283 267 251 235 219 203 187 171 155 139 123 107 91 75 59 43 27 11 Reading symbols from /boot/kernel/zfs.ko...Reading symbols from /bootdir/boot/kernel/zfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/zfs.ko Reading symbols from /boot/kernel/opensolaris.ko...Reading symbols from /bootdir/boot/kernel/opensolaris.ko.symbols...done. done. Loaded symbols for /boot/kernel/opensolaris.ko Reading symbols from /boot/kernel/accf_http.ko...Reading symbols from /bootdir/boot/kernel/accf_http.ko.symbols...done. done. Loaded symbols for /boot/kernel/accf_http.ko Reading symbols from /boot/kernel/ipmi.ko...Reading symbols from /bootdir/boot/kernel/ipmi.ko.symbols...done. done. Loaded symbols for /boot/kernel/ipmi.ko Reading symbols from /boot/kernel/smbus.ko...Reading symbols from /bootdir/boot/kernel/smbus.ko.symbols...done. done. Loaded symbols for /boot/kernel/smbus.ko Reading symbols from /boot/kernel/pflog.ko...Reading symbols from /bootdir/boot/kernel/pflog.ko.symbols...done. done. Loaded symbols for /boot/kernel/pflog.ko Reading symbols from /boot/kernel/pf.ko...Reading symbols from /bootdir/boot/kernel/pf.ko.symbols...done. done. Loaded symbols for /boot/kernel/pf.ko #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump () at pcpu.h:195 #1 0x0004 in ?? () #2 0x8050df79 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:418 #3 0x8050e382 in panic (fmt=0x104 ) at /usr/src/sys/kern/kern_shutdown.c:574 #4 0x807d2253 in trap_fatal (frame=0xff0315455370, eva=Variable "eva" is not available. ) at /usr/src/sys/amd64/amd64/trap.c:757 #5 0x807d2625 in trap_pfault (frame=0x7b6a2780, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:673 #6 0x807d2f64 in trap (frame=0x7b6a2780) at /usr/src/sys/amd64/amd64/trap.c:444 #7 0x807b70ce in calltrap () at /usr/src/sys/amd64/amd64/
Re: Going to BSD 8 from RELENG_7
On 14/08/09 11:12 AM, Dan Allen wrote: I cvsup and build RELENG_7 many times a week. This has served me well (except for the ZFS boot problem I had that went in and was backed out) for quite a while. I like to track a STABLE release. When BSD 7 went to 7.1 and to 7.2, it all just happened automatically with the way I do things. Now I am interested on one of my BSD machines to try 8.0. I need to change my cvsup target from RELENG_7 to CURRENT I believe. Is that true? When will STABLE become 8.0? Since I see you are updating from 7 to 8 and are running ZFS, you may be bitten by the fact that ZFS will not work after you install the new kernel. See the last comment here: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html Ari --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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.0-BETA2 Available
On 18/07/09 1:29 PM, Ken Smith wrote: # freebsd-update upgrade -r 8.0-BETA2 During this process, FreeBSD Update may ask the user to help by merging some configuration files or by confirming that the automatically performed merging was done correctly. # freebsd-update install The system must be rebooted with the newly installed kernel before continuing. # shutdown -r now FreeBSD 7 users who have /usr /var, etc on ZFS should not follow these instructions exactly. Rebooting into a new kernel with the old userland ZFS tools will result in the system not being able to mount the ZFS filesystems and therefore not being able to reboot. [1] Ari Maniatis [1] See my more detailed comment at the bottom here: http://www.daemonology.net/blog/2009-07-11-freebsd-update-to-8.0-beta1.html --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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 NAS configuration question
On 31/05/2009, at 4:41 AM, Dan Naumov wrote: To top that off, even when/if you do it right, not your entire disk goes to ZFS anyway, because you still do need a swap and a /boot to be non-ZFS, so you will have to install ZFS onto a slice and not the entire disk and even SUN discourages to do that. ZFS on root is still pretty new to FreeBSD, and until it gets ironed out and all the sysinstall tools support it nicely, it isn't hard to use a small UFS slice to get things going during boot. And there is nothing wrong with putting ZFS onto a slice rather than the entire disk: that is a very common approach. http://www.ish.com.au/solutions/articles/freebsdzfs Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: FreeBSD 7.2 Release process starting...
On 21/03/2009, at 10:49 PM, Robert Watson wrote: On Wed, 18 Mar 2009, kama wrote: What I meant was the todo page on www.freebsd.org. Like: http://www.freebsd.org/releases/7.2R/TODO.html Where problems and showstoppers where brought up. I found that information very valueble. Especially when the release went overdue I could easily see what caused the delay. The last release I did not really get information about why the release was delayed. At least not as easily as reloading a webpage. We do plan to create such a page, but are currently finding things to populate it with since we're early in the release process yet. We'll send out an e-mail once it's up. Is there any way to automatically create such a page from the bug tracker? Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: FreeBSD Update should be back to normal
On 09/01/2009, at 7:19 AM, Colin Percival wrote: 2. Assuming the first mirror still fails, use the -s option to pick a different mirror. Where can we find a list of mirrors? Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ 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: visibility of release process
On 09/12/2008, at 5:21 AM, Peter Jeremy wrote: What do you mean as "news source"? Commits are inherently low level and it's difficult to see how a commit could be massaged into some sort of press release without a fair amount of meta information in the commit log. Well, I use this as a way of tracking activity sometimes: http://news.gmane.org/gmane.os.freebsd.devel.cvs And indeed, I notice now it has been improved recently. The commit messages now include full paths and diffs. Very helpful. * the bug tracker. Let's just say that FreeBSD's bug tracker is fairly primitive and 'target release' is not an option. Agreed. This is an issue that comes up regularly but I don't believe a solution has been identified. I suspect one of the requirements would be that it be FOSS I don't understand why it should be necessarily FOSS. I believe the best solution should be chosen by those people who would use it most: the core developers. I know for a fact that many non-free providers would give FreeBSD a free perpetual license for the goodwill it would create, as for instance Atlassian do for Jira at Apache and other open source projects. Is it also a requirement that FreeBSD only be hosted on servers with FOSS bios? What about P4? My personal wish list would be: * rich search interface * workflow (eg. if a critical task remains open for more than x days without attention, it is automatically escalated) * svn integration (so that commit messages reference the task and vice versa) * release notes and roadmap * ease of integration with multiple front end tools, so developers can comment on issues from the command line or their iphone I've had a look at several of the fisheye sites and am not sure what it would buy the Project, other than some pretty graphs. I don't see how this is any more "friendly" than svn.freebsd.org. Sure, but show me how to go to http://svn.freebsd.org/viewvc/base/ and see commit log per branch or any other way to see what is going on in a branch. Fisheye gives you that in a really clear way and it costs nothing to add another option for users. Cheers Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
visibility of release process
I've resisted sending this email for a while since I really don't want to start a bikeshed nor a flame. However there comes a time to express my thoughts over the lack of visibility of the release process for FreeBSD 7.1. Here are the resources I am aware of: * release timeline [1]. This page makes no mention of beta 2 which is now some weeks old, so I assume the page is not actively used as a communication tool for the status of the release. * this list [2]. Although betas are announced here, there is no information about what is happening next. * subversion. Without checking out the whole repository, it is a little hard to use this as a news source and emails to the commit list still look more like cvs than svn so it is a bit hard to see which branch commits are going to. [3] * the bug tracker. Let's just say that FreeBSD's bug tracker is fairly primitive and 'target release' is not an option. I'd like to make several suggestions which could improve the transparency of the release process: 1. Short term fix: re could make a progress announcement on the appropriate lists every 14 days during the release process. Just a short summary of URLs pointing to the bug tracker. 2. Some web based friendly end-user visibility on the commit process, per branch. People can see what is going in and being fixed, but not what is left outstanding. Fisheye is an option because it costs nothing except the small load on the svn server. 3. Improvements to the bug tracker. Personally I'd love to see something like Jira used [4] with all the sophistication of workflow, release notes, voting for bugs, etc, etc. I'm happy to help with 2 and/or 3 in terms of contribution of my time and experience. Cheers Ari Maniatis [1] http://www.freebsd.org/releases/7.1R/schedule.html [2] That is FreeBSD-stable [3] I've also made an attempt to have Atlassian use Fisheye to produce an friendly overview of the repository, however I need to get permission from FreeBSD for this to happen before Atlassian will go ahead and index the whole svn repository. I've been unable to get anyone to respond to my requests in that regard. The result might look a bit like this: http://fisheye6.atlassian.com/ [4] Disclaimer: I am an Atlassian partner and like their products, but stand to gain nothing by the decision FreeBSD core make, I just think it is the best product for FreeBSD's requirements and it works well over at Apache. --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: can't freebsd-update from 7.1-PRERELEASE
On 05/12/2008, at 12:14 PM, Joan Picanyol i Puig wrote: Hi, Apparently 7.1-PRERELEASE has been pulled from freebsd-update's server while I was being lazy: calvin% sudo freebsd-update --debug upgrade -r 7.1-BETA2 Looking up update.FreeBSD.org mirrors... 1 mirrors found. Fetching metadata signature for 7.1-PRERELEASE from update1.FreeBSD.org... fetch: http://update1.FreeBSD.org/7.1-PRERELEASE/i386/latest.ssl: Not Found failed. No mirrors remaining, giving up. Yeah, this seems to be a problem in freebsd-update. You can workaround like this: # env UNAME_r=7.1-BETA freebsd-update upgrade -r 7.1-BETA2 Something got mixed up in the naming of the releases and freebsd- update gets confused. Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Replication system
On 04/11/2008, at 8:35 AM, Jordi Espasa Clofent wrote: At first approach I've thought in rsync+cron, but unison [1] works really well for us. In some ways it is better than some sort of shared SAN type solution since there is no single point of failure at the SAN or link to the SAN. Unison is just two way rsync so that changes can propagate in both directions between servers. Ari [1] http://www.cis.upenn.edu/~bcpierce/unison/ --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysctl maxfiles
On 28/09/2008, at 8:18 AM, Gary Palmer wrote: At least one port recommends you set kern.maxfiles="4" in /boot/loader.conf. I think its one of the GNOME ports. I'm pretty confident you can run that without too many problems, and maybe go higher, but if you really want to know the limit its probably kernel memory and that will depend on your workload. I guess then I should ask the question a different way. How much memory does each fd use and which pool of memory does it come from? This is ZFS if that makes any difference. Or asked a different way, if I set the number to 200,000 and some rogue process used 190,000 fds, then what bad thing would happen to the system? If any. Solving the fd leak is by far the safest path. Note that tracking that many files is probably affecting your application performance in addition to hurting the system. Absolutely. We are working on it. But general Unix principles are that a non-root user should not be able to get Unix to a non-functional state. It appears that this is a very simple path to DoS, particularly since with the default settings it is easy for one process to use up all available fds and leave no more for anyone to be able to log in. Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sysctl maxfiles
On 27/09/2008, at 1:02 PM, Jeremy Chadwick wrote: Anyway, I'd like to know why you have so many fds open simultaneously in the first place. We're talking over 11,000 fds actively open at once -- this is not a small number. What exactly is this machine doing? Are you absolutely certain tuning this higher is justified? Have you looked into the possibility that you have a program which is exhausting fds by not closing them when finished? (Yes, this is quite common; I've seen bad Java code cause this problem on Solaris.) Well, there was a runaway process which looks like it is leaking fds. We haven't solved it yet, but the fact that the maxfiles per machine and the maxfiles per process were so close together was really causing us grief for a while. You're asking for trouble setting these values to the equivalent of unlimited. Instead of asking "what would happen", you should be asking "why would I need to do that". Regarding memory implications, the Handbook goes over it. Unfortunately I've been unable to find it. While we fix the fd leak I'd like to know how high I can push these numbers and not cause other problems. Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
sysctl maxfiles
By default FreeBSD 7.0 shipped with the sysctls set to: kern.maxfiles: 12328 kern.maxfilesperproc: 11095 We recently bumped up against these limits in an unfortunate way and we are going to raise them. I have some questions: * why are the numbers set the way they are? They aren't round numbers, they aren't powers of 2. But they were arrived at somehow with planning and thought presumably, so when I increase them I'd like to know a bit more about why these numbers were chosen. * why are the numbers so close together? Surely there should be more gap between max files per process and the max files for the whole system. What happens is that with one runaway broken process is that it hits 11095 and the 1233 files left for everything else is not enough (on many servers) to allow the admin to login using ssh. That gets very ugly very quickly. * Under OSX (both server and client), these numbers are 12288 and 10240. A bit more of a gap, but not terribly different to FreeBSD. Still interesting that someone changed these numbers just slightly. * why do these controls exist at all? That is, if they were set to infinite what part of the system would be exhausted by a runaway process which kept opening files? Would the kernel run out of memory? What memory setting would be relevant here? I don't want to set maxfiles too high and then run out of some other resource which this maxfiles was protecting. Thanks Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Upcoming Releases Schedule...
On 21/09/2008, at 10:34 AM, netgeek wrote: Perhaps there is a middle ground here? What about a statement that each major branch (6.x, 7.x) will be supported for at least 24+ months from its last production release? Smaller periods of support could be given to minor releases along the way (7.2, for example), but at least companies would know that if they installed a 6.x version, they'd have support for a couple of years, even if that might mean upgrading to a newer minor version if there was a problem. This is already the case [1]. From each major branch one or more releases are designated as 'extended' and supported for 24 months. All you have to do is pick one of those and you've got support for 24 months. For example 6.3 has extended support in this way. RELENG_6 itself will be supported 24 months after the last release. Given roughly 18 months between major releases and about 12 months of ongoing releases from the previous branch after that, 4.5 years is roughly how long each major branch is supported for. That is already clear as could be. I can't quite understand what Jo Rhett is offering to the community that he is upset isn't being taken up. I think he wants some other arbitrary point release to be given extended support, either because in his case 24 months is not enough, or because he wants every release to have 24 months of support, or something else, I'm not sure. Jo, you say that he have had to maintain your own patched build of old FreeBSD releases because you need to keep them in production for longer than EoL period. Can I suggest that the first step is for you to publish those patches somewhere public and allow others to have access to them. Then you'll have a chance of convincing others to contribute to your patch sets and eventually of convincing FreeBSD to officially sanction them. Go and create a new sourceforge project or convince your boss to set aside some space on his web site/svn server/ etc for this project. Tell him that if it goes well, you'll be creating a whole lot of good will for the company in addition to the prospect of getting other people to contribute and share the work. Ari Maniatis [1] http://security.freebsd.org/ --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
infrastructure
How do I get in touch with FreeBSD infrastructure people about mailing list set up? Sorry to post here, but I've scoured the web site and cannot find anything more appropriate. Is there a [EMAIL PROTECTED] or something similar? I tried [EMAIL PROTECTED] in relation to the specific question I had, but that address bounced, even though mailman has it advertised as the owner address for the list in question. Thanks Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Multi-machine mirroring choices
On 15/07/2008, at 3:54 PM, Jeremy Chadwick wrote: We moved all of our production systems off of using dump/restore solely because of these aspects. We didn't move to ZFS though; we went with rsync, which is great, except for the fact that it modifies file atimes (hope you use Maildir and not classic mbox/mail spools...). We do something similar, except that we use unison rather than rsync. This tool is a two way rsync, it deals with collisions and replicating files in both directions at once. Very nice. Look for it in the ports tree. This has some advantages for us since we distribute load across several machines and have a cluster of machines which all replicate to each other. The data is such that collisions are almost never a concern. Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR on sleepqueue chain locks, Was: LOR sleepq/scrlock
On 23/04/2008, at 3:34 AM, John Baldwin wrote: The real problem at the bottom of the screen though is a real issue. It's a LOR of two different sleepqueue chain locks. The problem is that when setrunnable() encounters a swapped out thread it tries to wakeup proc0, but if proc0 is asleep (which is typical) then its thread lock is a sleep queue chain lock, so waking up a swapped out thread from wakeup() will usually trigger this LOR. I think the best fix is to not have setrunnable() kick proc0 directly. Perhaps setrunnable() should return an int and return true if proc0 needs to be awakened and false otherwise. Then the the sleepq code (b/c only sleeping threads can be swapped out anyway) can return that value from sleepq_resume_thread() and can call kick_proc0() directly once it has dropped all of its own locks. -- John Baldwin The way you describe it, it almost sounds like this LOR should be happening for everyone, all the time. To try and eliminate the factors which trigger it for us, we tried the following: removed PAE from kernel, disabled PF. Neither of these things made any difference and the error is fairly quickly reproducible (within a couple of hours running various things to load the machine). The one thing we did not test yet is removing ZFS from the picture. Note also that this box ran for years and years on FreeBSD 4.x without a hiccup (non PAE, ipfw instead of pf and no ZFS of course). There are two things. 1) Most people who run witness (that I know of) don't run it on spinlocks because of the overhead, so LORs of spin locks are less well-reported than LORs of other locks (mutexes, rwlocks, etc.). 2) You have to have enough load on the box to swap out active processes to get into this situation. Between those I think that is why this is not more widely reported. Hi John, Thanks for your efforts so far to track this LOR down. I've been keeping an eye on cvs logs, but haven't seen anything which looks like a patch for this. * is this still outstanding? * or will it be addressed soon? * if not, should I create a PR so that it doesn't get forgotten? * in our case, although we can trigger it quickly with some load, the problem occurs (and causes a complete machine lock) even under < 10% load. Not sure if the combination of PAE/ZFS/SCHED ULE exacerbates that in any way compared to a 'standard' build. Thank you Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LOR on sleepqueue chain locks, Was: LOR sleepq/scrlock
On 19/04/2008, at 3:14 AM, John Baldwin wrote: On Thursday 10 April 2008 06:33:40 pm Aristedes Maniatis wrote: http://www.ish.com.au/s/LOR/1.jpg http://www.ish.com.au/s/LOR/2.jpg http://www.ish.com.au/s/LOR/3.jpg (this overlaps with [2]) These are all garbage in kuickshow. :( They work fine for me in Firefox. But don't know what sort of jpegs the Sony camera saves. Anyhow I've also now resaved them as png (about twice the size). Please let me know if that worked. http://www.ish.com.au/s/LOR/1.png , etc kuickshow had issues still, but FF worked ok. The specific LOR at the end is real, but a minor one. Basically, the console driver locks (e.g. "sio", "scrlock") are higher in the order than the various thread locks, so any printf while holding a thread lock will trigger a LOR. The real problem at the bottom of the screen though is a real issue. It's a LOR of two different sleepqueue chain locks. The problem is that when setrunnable() encounters a swapped out thread it tries to wakeup proc0, but if proc0 is asleep (which is typical) then its thread lock is a sleep queue chain lock, so waking up a swapped out thread from wakeup() will usually trigger this LOR. I think the best fix is to not have setrunnable() kick proc0 directly. Perhaps setrunnable() should return an int and return true if proc0 needs to be awakened and false otherwise. Then the the sleepq code (b/c only sleeping threads can be swapped out anyway) can return that value from sleepq_resume_thread() and can call kick_proc0() directly once it has dropped all of its own locks. -- John Baldwin The way you describe it, it almost sounds like this LOR should be happening for everyone, all the time. To try and eliminate the factors which trigger it for us, we tried the following: removed PAE from kernel, disabled PF. Neither of these things made any difference and the error is fairly quickly reproducible (within a couple of hours running various things to load the machine). The one thing we did not test yet is removing ZFS from the picture. Note also that this box ran for years and years on FreeBSD 4.x without a hiccup (non PAE, ipfw instead of pf and no ZFS of course). Since I've ordered a replacement machine to go into production now, I am happy to make this one available for whatever testing would benefit the FreeBSD community to track down the problem. If useful, we could upgrade this machine to 7 STABLE branch and use the new tools Robert Watson recently wrote to dump better crash logs. Let me know, but I don't know a lot about them yet apart from what I read on this list. Regards Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR sleepq/scrlock
On 08/04/2008, at 6:06 PM, Aristedes Maniatis wrote: LOR: 1st 0x807d3d90 sleepq chain (sleepq chain) @/usr/src/sys/kern/ subr_sleepqueue.c:773 2nd 0x807c8110 scrlock (scrlock) @/usr/src/sys/dev/syscons/syscons.c: 2526 Is there anything I can do at my end to assist in the debugging of this issue? Should I create PR for it? Is there enough information to locate the issue, or will it require further tests from me? Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR sleepq/scrlock
http://www.ish.com.au/s/LOR/1.jpg
http://www.ish.com.au/s/LOR/2.jpg
http://www.ish.com.au/s/LOR/3.jpg (this overlaps with [2])
These are all garbage in kuickshow. :(
They work fine for me in Firefox. But don't know what sort of jpegs
the Sony camera saves. Anyhow I've also now resaved them as png (about
twice the size). Please let me know if that worked.
http://www.ish.com.au/s/LOR/1.png , etc
Not PAE. If there was a panic or printf inside the kernel sleep
queue code
itself then you might get this LOR as a side effect, but the real
problem
would be the original panic or printf.
The set up of this machine is identical (as far as possible) with
another happy machine. The difference is different hardware (such as
NIC hardware and CPU) and that this is running PAE and the other
AMD64. I know that introduces a lot of different code, so it may not
be a useful comparison.
Another data point is that we switched the scheduler ('sleep queue'
sounds vaguely like something scheduler related to us) from 4BSD to
ULE with no change in behaviour.
This is starting to cause us some grief with this machine offline, so
we might need to throw some new hardware at the problem and hope the
issue goes away. I am just afraid that the problem might follow us if
the issue is rooted in our setup rather than the hardware choices.
Thanks
Ari
-->
ish
http://www.ish.com.au
Level 1, 30 Wilson Street Newtown 2042 Australia
phone +61 2 9550 5001 fax +61 2 9550 4001
GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: LOR sleepq/scrlock
On 08/04/2008, at 11:59 PM, John Baldwin wrote: On Tuesday 08 April 2008 04:06:24 am Aristedes Maniatis wrote: FreeBSD dash.ish.com.au 7.0-RELEASE FreeBSD 7.0-RELEASE #10 i386 with PAE (5Gb RAM) We've had fairly reproducible freezes. After several hours of stress testing or even overnight not doing anything, everything locks up including the console. We then installed a debugging kernel (without INVARIANTS since that prevented the kernel from compiling at all) and obtained this LOR when it froze: LOR: 1st 0x807d3d90 sleepq chain (sleepq chain) @/usr/src/sys/kern/ subr_sleepqueue.c:773 2nd 0x807c8110 scrlock (scrlock) @/usr/src/sys/dev/syscons/syscons.c: 2526 I have taken photographs of the KDB output following this but have not transcribed it until someone says that it will be useful to them. I could put it up as slightly fuzzy screen photographs on our web site. The stack trace info would be useful. A photo would be fine. -- John Baldwin Sorry for the quality, these were the best I could do with the camera I had: http://www.ish.com.au/s/LOR/1.jpg http://www.ish.com.au/s/LOR/2.jpg http://www.ish.com.au/s/LOR/3.jpg (this overlaps with [2]) Do you have any hunch about what driver/system might be causing this? Could it be related to the use of PAE? Because if so, I'd be happy to leave this server accessible somewhere for FreeBSD developers to work with and go replace it with a new 64bit system tomorrow for our production use. Thanks Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
LOR sleepq/scrlock
FreeBSD dash.ish.com.au 7.0-RELEASE FreeBSD 7.0-RELEASE #10 i386 with PAE (5Gb RAM) We've had fairly reproducible freezes. After several hours of stress testing or even overnight not doing anything, everything locks up including the console. We then installed a debugging kernel (without INVARIANTS since that prevented the kernel from compiling at all) and obtained this LOR when it froze: LOR: 1st 0x807d3d90 sleepq chain (sleepq chain) @/usr/src/sys/kern/ subr_sleepqueue.c:773 2nd 0x807c8110 scrlock (scrlock) @/usr/src/sys/dev/syscons/syscons.c: 2526 I have taken photographs of the KDB output following this but have not transcribed it until someone says that it will be useful to them. I could put it up as slightly fuzzy screen photographs on our web site. I am somewhat concerned about the combination of PAE (being slightly old technology now) and zfs (being cutting edge), not having a huge amount of testing against each other. However nothing in this lock seems to suggest zfs to me. The only unusual thing on this box is this: hw.physmem: 1063911424 actual memory is half that, but I thought this might be a side effect of PAE. Then, restarting the machine and it hit a couple of LOR errors in quick succession. I can't see any exact matches to http://sources.zabbadoz.net/freebsd/lor.html However the box boots normally after these LOR, so they may not be fatal and may not be related to the above, but just in case... lock order reversal: 1st 0x862f9204 inp (udpinp) @ /usr/src/sys/netinet/udp_usrreq.c:843 2nd 0x8081f498 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 KDB: stack backtrace: db_trace_self_wrapper(807430c0,c3d639fc, 80438ff5,80744463,8081f498,...) at db_trace_self_wrapper+0x26 kdb_backtrace(80744463,8081f498,8074a8c5,8074a8c5,8074a8ad,...) at kdb_backtrace+0x29 witness_checkorder(8081f498,1,8074a8ad,49,807528d7,...) at witness_checkorder+0x5e5 _rw_rlock(8081f498,8074a8ad,49,0,c3d63ab8,...) at _rw_rlock+0x2a pfil_run_hooks(8081f480,c3d63ad8,83931800,2,862f9168,...) at pfil_run_hooks+0x35 ip_output(867ea700,0,c3d63a9c,0,0,...) at ip_output+0x86f udp_send(862f77bc,0,867ea700,83c91bb0,0,...) at udp_send+0x57b sosend_dgram(862f77bc,83c91bb0,c3d63bd4,867ea700,0,...) at sosend_dgram +0x356 sosend(862f77bc,83c91bb0,c3d63bd4,0,0,...) at sosend+0x3f kern_sendit(84cad660,1e,c3d63c58,0,0,...) at kern_sendit+0x106 sendit(0,1,c3d63c54,28,83c91c60,...) at sendit+0xb1 sendmsg(84cad660,c3d63cfc,c,84cad660,807845c0,...) at sendmsg+0x71 syscall(c3d63d38) at syscall+0x2b3 Xint0x80_syscall() at Xint0x80_syscall+0x20 --- syscall (28, FreeBSD ELF32, sendmsg), eip = 0x2842415b, esp = 0x7f3fc7fc, ebp = 0x7f3fc818 --- lock order reversal: 1st 0x8082010c tcp (tcp) @ /usr/src/sys/netinet/tcp_input.c:400 2nd 0x8081f498 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 KDB: stack backtrace: db_trace_self_wrapper(807430c0,c16039ec, 80438ff5,80744463,8081f498,...) at db_trace_self_wrapper+0x26 kdb_backtrace(80744463,8081f498,8074a8c5,8074a8c5,8074a8ad,...) at kdb_backtrace+0x29 witness_checkorder(8081f498,1,8074a8ad,49,807528d7,...) at witness_checkorder+0x5e5 _rw_rlock(8081f498,8074a8ad,49,0,c1603aa8,...) at _rw_rlock+0x2a pfil_run_hooks(8081f480,c1603ac8,83935000,2,0,...) at pfil_run_hooks +0x35 ip_output(8394ed00,0,c1603a8c, 0,0,0,80796f90,0,0,0,804b2971,80796f94,80796f9c,c8) at ip_output+0x86f tcp_respond(0,83984830,83984844,8394ed00,46ca580,...) at tcp_respond +0x395 tcp_dropwithreset(1,3,99e2,873e1dcb,1600,...) at tcp_dropwithreset+0x126 tcp_input(8394ed00,14,83935000,1,0,...) at tcp_input+0xcf9 ip_input(8394ed00,14e,800,83935000,800,...) at ip_input+0x64a netisr_dispatch(2,8394ed00,10,3,0,...) at netisr_dispatch+0x55 ether_demux(83935000,8394ed00,3,0,3,...) at ether_demux+0x1c1 ether_input(83935000,8394ed00,8072d03c,6a9,83922014,...) at ether_input +0x323 fxp_intr(83922000,0,8073e924,471,8384a764,...) at fxp_intr+0x237 ithread_loop(839219b0,c1603d38,8073e756,305,838fc804,...) at ithread_loop+0x145 fork_exit(803ee250,839219b0,c1603d38) at fork_exit+0x94 fork_trampoline() at fork_trampoline+0x8 --- trap 0, eip = 0, esp = 0xc1603d70, ebp = 0 --- lock order reversal: 1st 0x86c5809c inp (tcpinp) @ /usr/src/sys/netinet/tcp_usrreq.c:470 2nd 0x8081f498 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:73 KDB: stack backtrace: db_trace_self_wrapper (807430c0,c39d7a30,80438ff5,80744463,8081f498,...) at db_trace_self_wrapper+0x26 kdb_backtrace(80744463,8081f498,8074a8c5,8074a8c5,8074a8ad,...) at kdb_backtrace+0x29 witness_checkorder(8081f498,1,8074a8ad,49,807528d7,...) at witness_checkorder+0x5e5 _rw_rlock(8081f498,8074a8ad,49,0,c39d7aec,...) at _rw_rlock+0x2a pfil_run_hooks(8081f480,c39d7b0c,839d3400,2,86c58000,...) at pfil_run_hooks+0x35 ip_output(867ce300,0,c39d7ad0,0,0,...) at ip_output+0x86f tcp_output(86c59000,0,8074feb4,1d6,8
Re: Backup solution suggestions
On 15/01/2008, at 8:52 PM, Johan Ström wrote: I'm looking to invest in some new hardware for backup. probably some kind of NAS (a 4-disk 1U NAS or something in that size). The thing is that I won't be the only one with access to this box, thus I would like to secure my data. What I would like is encryption both for the transfer to the box, and encrypted on disk. The data on disk should not be readable by anyone but me (ie the other user(s) of the box should not be able to read it, at least not without a big effort). Take a look at bacula. It is a proper backup system, meaning that it does incremental backups, etc. Storage pools can be encrypted. Not sure if the network stream can be, but that could be solved with an ssh tunnel. And it is open source, reliable and runs nicely on FreeBSD. Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: BIND 9.3.1 - How to get rid of AAAA querys?
On 14/09/2007, at 12:23 PM, Ian Smith wrote: http://www.circleid.com/posts/ipv6_extinction_evolution_or_revolution/ The author of that interesting article is one of the speakers at a summit in Canberra, Australia in November this year discussing the migration to IPv6. Geoff Huston was responsible for some of the original internet rollouts in Australia when it was all still run by the AVCC (Australia vice-chancellors committee). http://www.ipv6.org.au/summit/speakers.html Personally, I cannot wait until NAT, STUN and all that nonsense goes away. Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: FreeBSD 4 EOL ports tree
On 19/04/2007, at 9:05 AM, Gabor Kovesdan wrote: RELEASE_4_EOL is the tag where the 4.X support was not yet removed. We only started to remove the 4.X support after the tag, thus you should still be able to build ports from the tag on 4.X. My installations use portsnap and so automatically went past the correct tag. Is there a way to get portsnap to downgrade the ports tree now to 4_EOL or is the best way to install cvsup and do it? Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: sendmail_enable="NO"
On 01/01/2006, at 9:38 AM, Forrest Aldrich wrote: Isn't this supposed to tell FreeBSD not to start up the sendmail daemon processes? Have a read of /etc/defaults/rc.conf and try the sendmail_enable="NONE" flag. Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: HEADS UP: MFC of local_startup changes to rc.d complete
On 21/12/2005, at 7:23 PM, Doug Barton wrote: As has been discussed for a couple weeks now, I have MFC'ed to RELENG_6 the changes in /etc/rc* that bring new-style boot scripts from the local_startup directories (by default /usr/local/etc/rc.d and /usr/X11R6/etc/rc.d) into the base rcorder. How does this correlate with the planned implementation of launchd in FreeBSD? http://wikitest.freebsd.org/moin.cgi/launchd Perhaps it is too early for you to say, but it would seem that launchd is a much more sophisticated system that would bring a whole range of benefits to FreeBSD. Is work still progressing on that? Will these changes to /etc/rc allow for a migration path? Cheers Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GENERIC and DEFAULTS
On 03/11/2005, at 9:09 AM, David Wolfskill wrote: On Wed, Nov 02, 2005 at 04:39:30PM -0500, Ken Menzel wrote: ... If I include GENERIC can I comment out the following? #cpuI486_CPU #cpuI586_CPU Well, it's your (copy of) the file; I suppose you can do whatever you want to with it. :-) Ken's original point is a valid one. The way we have created config files in the past was to duplicate GENERIC and edit the copy. Recent postings have indicated that the new methodology will be to 'include' GENERIC and override certain features using the nodevice tag. This sounds like a great idea to avoid using diff to figure out what crucial features changed from one release to another. But it will only be useful if we don't have to edit the GENERIC file. Otherwise we are back where we started, editing a file which is overwritten by cvsup. Ari Maniatis --> ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Remote firewall changes, Was: Newbie Question About System Update
On 20/04/2005, at 6:05 AM, Scott Robbins wrote: (And of course the obvious--DO NOT shut down the sshd daemon.) :) Ok, everyone who has NEVER ever made that mistake (or locked themself out with a firewall rule, accidentally putting it into effect before testing) raise their hand. :) Yes, that would be me. But someone taught me a great trick...the "at" command. So, just before you blow away your access with changes to ipfw, do this: echo "ipfw add 1 pass all from any to any" at now +10 minutes Then if all goes OK, use atq to remove the queue item. If not, wait 10 minutes... Ari Maniatis --> ish group http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
aac support for Adaptec 2020SA ZCR
We have a motherboard (Supermicro X6DHT-G) with an Adaptec 2020SA SATA RAID controller. We have been unable to get any drives recognised by the FreeBSD 5.3 release installation CD, and we've been unable to find much discussion about the status of the AAC device and support for this chipset. Several other Adaptec SATA RAID controllers seem to be supported: 2410SA, 2810SA, 21610SA. The logical drive configured in the RAID controller is detected successfully in a Gentoo Linux 2004.3 environment. Has anyone had success with this controller? Any alternative you would recommend or will support be available in 5.4? I believe from the source code that the driver is maintained by Scott Long and that recent changes have been taking place. Thanks for any assistance. Ari Maniatis --> ish group pty ltd http://www.ish.com.au 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Can FreeBSD 5.3R support the RAID card MegaRAID SCSI 320-2E card?
On 05/03/2005, at 7:00 PM, Doug White wrote: The amr(4) manpage in -CURRENT lists the 320 variants, the -2E specifically (is that a PCI Express version?). We have a amr(4) driver update coming in shortly to -CURRENT and then RELENG_5; keep an eye out for that and test it if you can. * will that update make it into 5.4? * what is the nature of the update? Is it primarily for bug fixes or performance improvements? Is it an important update for someone running a production machine with amr (like us) on 5.3? Cheers Ari --> ish group pty ltd http://www.ish.com.au 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gvinum or vinum in 5.3-STABLE
Sorry to butt in on your thread, but it seems relevant. I am having problems with gvinum under 5-STABLE and a RAID 0 array of two disks. The array works perfectly until reboot. Then, when the machine comes back up the plexes are marked as stale. Issuing these commands fixes the problem until the next reboot: gvinum setstate up storage.p0.s0 gvinum setstate up storage.p0.s1 Things I've tried: * Googling for answers * commenting out the fstab entry at boot and then manually mounting the partition after boot * inserting gvinum in /boot/loader.conf * copying the vinum script in /etc/rc.d/vinum and making a gvinum equivalent * trying to shutdown gvinum at shutdown time (but "gvinum stop" doesn't work) * fsck * rebuilding gvinum array Is there some shutdown procedure that should gracefully shutdown the RAID? There is a process which opens files on the RAID and runs continuously until shutdown. Could it be holding the RAID open too long and could this staleness? From what I can tell the staleness doesn't affect any data - everything is OK once brought up. Cheers Ari Maniatis On 14/02/2005, at 11:38 AM, Tristan wrote: Is gvinum ready for production use in a RAID5 config ? --> ish group pty ltd http://www.ish.com.au 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
4.8 hyperthreading changes
From the 4.8 changes page I found this: FreeBSD now has rudimentary support for HyperThreading (HTT). SMP kernels with the HTT kernel option will detect and start up the logical processors on HTT-capable machines. The logical processors will be treated like additional physical processors for the purposes of process scheduling. On the 4.7 deployment systems I am running I have dual Xeon CPUs with hyperthreading. They appear as 4 CPUs in 'top'. That would seems to indicate to me that FreeBSD is scheduling them as four separate processors, however the note from: http://www.freebsd.org/relnotes/4-STABLE/relnotes/i386/x19.html#KERNEL makes it seem like this is a new 4.8 feature. Should I be concerned about upgrading when 4.8 is released in order to obtain the benefits of better use of these CPUs? Ari Maniatis --> ish group pty ltd 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 http www.ish.com.au | email [EMAIL PROTECTED] PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: update strategies
OK. This is where I get confused. I thought that the point of putting these applications into the base FreeBSD distribution was that they need to be tightly integrated into the OS. I understand that this is critical for basic system tools like "adduser". It appears this makes it important to build the whole distribution together (buildworld) and not get one tool out of sync with the rest. But if this is not the case, and we are supposed to build portions of the /usr/src/ without rebuilding the whole thing, why aren't these tools in /usr/ports? I'm new here, so I'm not telling you how to suck eggs. Perhaps there are historical reasons for this hierarchy. But I want to make sure I do the right thing. Is this the safest approach: * install ports for named, ssh, etc. * disable the base FreeBSD distributions of these tools * use cvsup to update these tools whenever I need to because of security/bugs/features * use cvsup to update base FreeBSD (src-all) for each tagged release (every 3 months or sooner in case of problems). Or less often if the update doesn't look important. Then buildworld to build a consistent FreeBSD release. Cheers Ari Maniatis On Sunday, December 8, 2002, at 12:40 PM, David Magda wrote: You don't have to rebuild world: # cd /usr/src/usr.sbin/named # make # make install should work fine. The resultant binary after the 'make' is in the /usr/obj hierachy. --> ish group pty ltd 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 http www.ish.com.au | email [EMAIL PROTECTED] PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
update strategies
I'm new here, and I've been lurking to look for answers. You seem like a friendly bunch, so I'll ask my question. It appears that there are two strategies for updating FreeBSD systems: * cvsup the latest STABLE release on a regular basis * get the CD release (4.6, 4.7, etc) snapshots periodically and update from that either with binaries or compiled from source I am curious about what most people do. For a server where stability is important, I obviously don't want to buildworld once a week, but it is also important to keep on top of bug reports and security holes. I am already using cvsup with the ports tree and it works really nicely, giving me the choice of what to update and when. Am I right in saying that the base FreeBSD install can work the same way? I guess what makes more more confused is figuring out what is part of "FreeBSD" and what is part of the ports. Some things seem to be both: eg. perl and bind. Is there a map somewhere that sets this out clearly? Does everything which is a port get installed in /usr/local? I'm having some problems getting the kernel to compile (errors in "/usr/src/sys/modules/linux") and I suspect that the problem may be due to this lack of understanding about which source trees live where. Thanks for any help Ari Maniatis --> ish group pty ltd 7 Darghan St Glebe 2037 Australia phone +61 2 9660 1400 fax +61 2 9660 7400 http www.ish.com.au | email [EMAIL PROTECTED] PGP fingerprint 08 57 20 4B 80 69 59 E2 A9 BF 2D 48 C2 20 0C C8 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
