Re: [gentoo-user] Suggestions? Network monitoring scripts
fire-eyes wrote: > > I'm looking for suggestions on software which could do the following 1) > if our primary gateway goes down, do nothing 2) if it does go down, > change the default gateway to line B 3) when the primary comes back, set > the gateway back to B. I have two physical interfaces and one alias. Hi again I did something similar on a RedHat system with modems hooked up to different telcos and ISPs some years ago. I no longer have the scripts to hand, but they were similar in consept to the example posted to this list under the thread 'Load Balancing / Redundant Network ?' today. I think I just set the default route off of the box, which in my case brought up the second PPP connection. I had one script constantly checking the status of the primary PPP line and one checking the status of the active line. The primary monitor would test the line every five minutes and switch to/from the secondary as necessary. There were some rules to not switch every five minutes in case the primary line was having a bout of intermittent problems. I think I left the secondary up for at least 30 minutes if ever it was switched to. The active monitor reported loss of the currently active line and what it was doing about it, especially if it was the secondard i/f and the primary was still flagged as failing. Is that the sort of thing you're looking for or do you need a 'proper' package? IanC -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Suggestions? Network monitoring scripts
fire-eyes wrote: > > I'm looking for suggestions on software which could do the following 1) > if our primary gateway goes down, do nothing 2) if it does go down, > change the default gateway to line B 3) when the primary comes back, set > the gateway back to B. I have two physical interfaces and one alias. > -- > gentoo-user@gentoo.org mailing list Are there some typos in there? Are there three interfaces on the Gentoo box: one LAN and one each to the external (WAN? Internet?) interfaces? IanC -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Building Xorg - internal compiler error: segmentation fault
Frank Schafer wrote: > > Hi all, > > Somebody on b.g.o. suggests to try building with a vanilly kernel. Did > someone here make the same experience and if yes, will it run then on a > gentoo-kernel? Hi Not sure if you're talking in general about sig 11 on emerge, some specific problem with Xorg. Anyhow, I had this with various packages and found a few things helped: - Once I had a sig 11 a restart of the emerge would seg fault very soon. I suspected dodgy CPU or memory, so played with the cpuburn package. Curiously I found that running MMXburn (I think it was called) for a minute or so vastly extended how far into a build emerge would get. I have no idea what this program actually does, but I assumed it was heavily loading some memory or other so that when gcc started again it was given a different chumk to what it was getting previously. But that's all very hypothetical... - I used the FEATURES="keepwork" emerge... so that the work area was preserved and the emerge could continue from where it was. But this takes up a lot of disk space uless you manually delete them or use ebuild --clean once it's suceeded. - Install ccache to 'dynamically' cache/preserve the guts of whatever you're trying to build so that you don't need "keepwork". It's a bit slower, but easier to manage. - Do an emerge in a one line script something like this, so it'll loop around until it succeeds (best used with the FEATURES or ccache idea): while true; do emerge foo && break; done HTH IanC -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Determine the original installation date
"Vernon A. Fort" wrote: > > With redhat/fedora, you could find WHEN the box was installed using rpm > -qi basesystem. I am switching most of my boxes to gentoo and I would > like to tell when the ORIGINAL install occured. Any pointers? Hi Possibly a little empirical, but on things like the mod date on the root lost+found directory and the first few lines of /var/log/emerge.log come to mind. IanC -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] issue on binary merge
Sascha Lucas wrote: > > emerge -1 --usepkg --pretend --verbose pkg_spec_from_equery > > then the change in USE-Flags are showen and my _correct_ binarys are used. > There's probably a good reason for it being the way it is, but it doesn't sound as transparent as we might like. A further interesting scenario might be to have a binary package available built with different USE flags to those on the target machine, and seeing if it gets installed or not. I guess it shouldn't. But then there's the CFLAGS issue as well, and I'm even more unsure how that's supposed to be handled. I'm still pretty new to Gentoo, but is this perhaps related to the feature I've read about (and maybe misremembered) regarding only packages that you explicity emerge going into world (dependencies don't)? I wonder if you'd see different results if you explicitly emerged cups rather than it having been implicity emerged due to a dependency. By doing the emerge you described you've 'promoted' those packages from implicit to explicit emerge. IanC -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] issue on binary merge
Sascha Lucas wrote: > > Hi List, > > Machine B: > - mount PGKDIR of machine A via nfs to PGKDIR on machine B > - added USE-flag "samba" > - emerge -uD --newuse --usepkg world > * merges binary samba > * does not merge anything else (no binary, no ebuild ) > > It would be nice if I understand why emerge won't remerge binary packages > with changed use-flags. Hi Sascha If you do --pretend --verbose, does it show the changed USE flags for the packages? Not sure if 'world' does this, but you could try the individual packages that you expect to be rebuilt. IIRC, it appears in green (on a colour screen...) with a + and * next to the USE flag. If the flags aren't shown as 'new' then its not strictly a problem with the merge, but one with the way the flag changes are being enumerated. If they are shown as changed then at least Portage is working out that it would like to have new builds of the packages, and any failure is presumably due to the way this cascades down to the binary merge mechanism, such as the ability of a binary package to declare what USE flags it was built with. Not a solution, but hopefully it'll add insight. IanC -- gentoo-user@gentoo.org mailing list
[gentoo-user] Is binary emerge equivalent to source emerge?
Hi I've been building a box for a specific purpose by emerge-ing and playing with various packages until I ended up with something that matched what I wanted. I'd now like to rebuild the box including just the packages that turned out to be relevant. Rather than do source installs again I was thinking of using the current box to build binary packages before wiping it and doing a rebuild from these binaries, hence saving on heaps of build time after setting make.conf, etc. to match the current install. One additional step that I think is important is to use a Portage snapshot from the current machine. A few questions... 1) Does this seem like a sensible idea? Will it generally work? 2) Will --usepkg --getbinpkg use binary packages for dependencies? 3) Is the resultant Portage database equivalent to source emerges, especially in respect of future --updates, --newuse, etc? 4) Am I right to use a Portage snapshot from the current machine? 5) Is this idea so close to the Catalyst idea that I should use its methods to achieve my aims? TIA IanC -- gentoo-user@gentoo.org mailing list
