February 2002 - WLUG - wlug.mailman3.com

network questions

by bryon3245＠netzero.com

I have a couple of questions. Why would you want a hub over a switch? What firewall under linux would you suggest, what would the best way to set up a firewall-router box with two nic's? Thanks for you'r help -------------------------------------------------------------------- mail2web - Check your email from the web at http://mail2web.com/ .

Feb. 17, 2002

Re: [Wlug] Newbie Answer.

by doug waud

doug waud wrote: too much :-) I thought I was writing to Andy and somehow wasted everyone's time Meanwhile, Frank Sweetser has summarized the situation well. doug

Feb. 16, 2002

Re: [Wlug] Newbie Answer.

by doug waud

> The reason that /etc/init.d/boot.local and /etc/rc.d/boot.local are the > same file is because /etc/rc.d is a link to /etc/init.d on my SuSE 7.2 PRO > system. > > linuxpc> ls -ald /etc/rc.d > lrwxrwxrwx 1 root root 6 Mar 24 2001 /etc/rc.d -> init.d Been there, done that :-) Actually, I tried root@233p5:/ > ls -al /etc/init.d/boot.local -rwxr--r-- 1 root root 447 Jan 30 16:37 /etc/init.d/boot.local root@233p5:/ > ls -al /etc/rc.d/boot.local -rwxr--r-- 1 root root 447 Jan 30 16:37 /etc/rc.d/boot.local | |____________________ | and found that both had the number 1 where I expected 2. I then went back to an old UNIX manual and did some more reading :-) and tried root@233p5:/ > ls -il /etc/init.d/boot.local 274722 -rwxr--r-- 1 root root 447 Jan 30 16:37 /etc/init.d/boot.local root@233p5:/ > ls -il /etc/rc.d/boot.local 274722 -rwxr--r-- 1 root root 447 Jan 30 16:37 /etc/rc.d/boot.local and, miracles still happen, got the same inodes for both files. So it looks like we have a hard link. However, we still have 1 and not 2 :-) I notice you have the same "disease" I then wondered whether SuSE was doing something odd. I therefore went to /tmp and, as root, created two subdirectories z1 and z2. I then cat'd /etc/fstab to z1/test1 to create a file. I finally created a hard link from z2/test1 to z1/test1. When I now did a ls -il on those two test1 files, there were 2's where they should be! At this point, Chuck suggested I do a forced fsck. I had some trouble at first (until he showed me I had to remount / ro; I had tried the SuSE rescue system but it complained about bad superblocks and/or odd "magic numbers". This happened on three boxes so I was unconvinced there was a screwed up file system on all three machines). I have just now finished that fsck -f /dev/hda7 on my notebook and all it reports is 0.2% non-contiguous --- as I suspected from the problem on three boxes (or 4, if we include yours) no screwed up file system. So the mystery now is why do we both get 1 for those linked files. doug filesystem.

Feb. 16, 2002

Re: [Wlug] Newbie Answer.

by Frank Sweetser

On Sat, Feb 16, 2002 at 12:02:40PM -0500, doug waud wrote: > I then went back to an old UNIX manual and did some more reading :-) and > tried > > root@233p5:/ > ls -il /etc/init.d/boot.local > 274722 -rwxr--r-- 1 root root 447 Jan 30 16:37 > /etc/init.d/boot.local > root@233p5:/ > ls -il /etc/rc.d/boot.local > 274722 -rwxr--r-- 1 root root 447 Jan 30 16:37 > /etc/rc.d/boot.local > > and, miracles still happen, got the same inodes for both files. So it > looks like we have a hard link. However, we still have 1 and not 2 :-) Aha - there's the confusion. There's no problem here - boot.local only has one directory entry (aka hardlink) pointing to it. /etc/init.d/ is a directory which contains a directory entry that maps the name boot.local to inum 274722. /etc/rc.d/ is *not* a directory, but rather a symlink. symlinks do not contain any information about that to which they point except the name, so it has no idea if it's pointing to a file, directory, dev entry, etc. So, when /etc/rc.d/foobar is opened, the symlink is hit and replaced with the contents of it's target -> /etc/init.d/foobar, and the entry foobar is looked up in the directory /etc/init.d/ Make sense? -- Frank Sweetser fs at wpi.edu, fs at suave.net | $ x 16 Full-time WPI Network Tech, Part time Linux/Perl guy | Tactical? TACTICAL!?!? Hey, buddy, we went from kilotons to megatons several minutes ago. We don't need no stinkin' tactical nukes. (By the way, do you have change for 10 million people?) --lwall

Feb. 16, 2002

Re: [Wlug] Newbie Answer.

by Andy Stewart

> > I did a > locate boot.local > and got back only > /etc/init.d/boot.local > > (I tried this on five machines here running > SusE 7.2 and they all showed just one copy) > > However, just to be sure, I went to /etc/rc.d and a ls -al > gave me that boot.local you describe! Hi Doug, The reason that /etc/init.d/boot.local and /etc/rc.d/boot.local are the same file is because /etc/rc.d is a link to /etc/init.d on my SuSE 7.2 PRO system. linuxpc> ls -ald /etc/rc.d lrwxrwxrwx 1 root root 6 Mar 24 2001 /etc/rc.d -> init.d Later, Andy -- Andy Stewart Founder Worcester Linux Users' Group Worcester, MA, USA http://www.wlug.org

Feb. 16, 2002

locate and updatedb

by doug waud

Frank Sweetser wrote: > > So now, I am at a loss as to why locate could not find /etc/rc.d/boot.local > > The locate command looks at the database that updatedb generates nightly > out of a cron job. The user that updatedb runs as probably doesn't have > permission to list the contents of the /etc/init.d/ directory. Made sense to me then, like a fool, I tried running updatedb as root and then, in belt-and-suspenders mode, I tried updatedb --localuser=root but still got only the boot.local in /etc/init.d :-( I guess this is why you let sleeping dougs lie doug

Feb. 14, 2002

Re: [Wlug] Newbie Answer.

by doug waud

Gregory Avedissian wrote re SuSE's boot.local > Any idea why the same file also exists in /etc/rc.d/ > along with boot.setup and some others? Direct answer, no :-( I did a locate boot.local and got back only /etc/init.d/boot.local (I tried this on five machines here running SusE 7.2 and they all showed just one copy) However, just to be sure, I went to /etc/rc.d and a ls -al gave me that boot.local you describe! So now, I am at a loss as to why locate could not find it :-( but, anyway ... I then poked around in the boot scripts (cf "SuSE Boot Concept" in the manual p 309 ff, or just man init.d ) and took a look at /etc/rc.d/boot --- the file init runs at the beginning. In there you can search for "local" (i.e. less /etc/rc.d/boot and then enter /local <return> followed by three N's each to move on to the Next place there is a "local" ) and see that init, the program that counts here, looks for and at /etc/init.d/boot.local. So this indicates it is the boot.local in /etc/rc.d which is the odd one. There also does not seem to be a symbolic link between them. With SuSE I am always suspicious of what SuSEconfig and /etc/rc.config are doing so I wondered whether SuSEconfig was looking at both boot.local files. But it seems to look at neither; in particular, it does not use one to update the other. I poked around on the web and, at http://www.linuxdoc.org/HOWTO/mini/Wacom-USB-mini-HOWTO-4.html found "Next I added in the /etc/rc.d/boot.local file (remember, I use a SuSE distribution, but you should fine an equivalent for RedHat in /etc/rc.d/init.d/boot.local or /etc/rc.d/init.d/rc.local)" This makes me think the /etc/rc.d location is atavistic, harking back to earlier versions of SuSE. I looked in my old 5.2 manual and could not see a clear proof of this but I do note that with the 7.2 SuSE version they seem to have tried to stick more closely to standards (page 287) so that old /etc/rc.d resting place may be in for some backwards compatibility with user's old scripts. My only problem with that theory is that I cannot find where the /etc/rc.d/boot.local file would get read in 7.2 The bottom line is clear --- use /etc/init.d/boot.local if you want to add a special modprobe or the like in recent SuSE distros. But, I'll still keep my eyes open for confirmation of the above or an alternative view. doug

Feb. 14, 2002

Re: [Wlug] Newbie Answer.

by Frank Sweetser

On Thu, Feb 14, 2002 at 05:41:05PM -0500, doug waud wrote: > Gregory Avedissian wrote re SuSE's boot.local > > > Any idea why the same file also exists in /etc/rc.d/ > > along with boot.setup and some others? > > Direct answer, no :-( > > I did a > locate boot.local > and got back only > /etc/init.d/boot.local > > (I tried this on five machines here running > SusE 7.2 and they all showed just one copy) > > However, just to be sure, I went to /etc/rc.d and a ls -al > gave me that boot.local you describe! > > So now, I am at a loss as to why locate could not find it :-( > but, anyway ... The locate command looks at the database that updatedb generates nightly out of a cron job. The user that updatedb runs as probably doesn't have permission to list the contents of the /etc/init.d/ directory. -- Frank Sweetser fs at wpi.edu, fs at suave.net | $ x 16 Full-time WPI Network Tech, Part time Linux/Perl guy | Just don't make the '9' format pack/unpack numbers... :-) -- Larry Wall in <199710091434.HAA00838(a)wall.org>

Feb. 14, 2002

Re: [Wlug] web bugs

by Josh Huber

"Charles R. Anderson" <cra(a)WPI.EDU> writes: > I made a reference to "web bugs" in a previous email. Those of you > who use HTML mail readers may be interested in this: > > http://www.privacyfoundation.org/resources/webbug.asp Yes, this is evil -- especially in spam email. I'm seeing it a lot lately in spam emails... Don't load images from remote servers in HTML email, basically. ttyl, -- Josh Huber

Feb. 14, 2002

Re: [Wlug] Killer Apps Image.

by Josh Huber

Aaron Haviland <orion(a)tribble.dyndns.org> writes: > ACK. I just recently started signing my emails, and hadn't realised > mutt's default behaviour in these cases: > > 6.3.124. pgp_strict_enc > > Type: boolean > Default: yes > > If set, Mutt will automatically encode PGP/MIME signed messages as > quoted-printable. Please note that unsetting this variable may lead > to problems with non-verifyable PGP signatures, so only change this if > you know what you are doing. > > I've disabled it. I hope I know what I'm doing... Well, you should be okay, unless you send messages with non-us characters in them, which some MTAs like to fiddle with. I think some MTAs like to screw with your message anyway, in some cases. But anyway, that's the rationale for this option being the default. ttyl, -- Josh Huber

Feb. 14, 2002