Re: A laptop installation challenge
AG writes: > > On one disk I found something that booted into the grub prompt. I > did some reading up on grub and some basic commands. I didn't get > very far - it reports back that there is an ext2fs loaded on > /dev/hda1 which I'm assuming was root, although I am sure that when > I partitioned the drive today I selected ext3. That's to be expected. Ext3 filesystems are basically ext2 filesystems with a journal. Many tools will recognize them as ext2 filesystems, and they can even be mounted, read, and written by pre-ext3 Linux kernels as if they were ext2 filesystems. And Andrew is right. If you've got a bootable GRUB disk, then you need to try that first. You didn't say what GRUB commands you tried, but did you try something like this: root (hd0,0) ls ## If this fails, try (hd0,1) or (hd0,2) until "ls" gives you what ## looks like your newly installed Debian root filesystem. kernel /boot/vmlinuz-xx.yy.zz-aa-generic root=/dev/hda1 initrd /boot/initrd.img-xx.yy.zz-aa-generic boot For the kernel and initrd file names, you can use to complete the filenames (or the GRUB "ls" command to poke around until you find the right names). The "root=/dev/hda1" option might not be necessary. Try with and without it. -- Kevin -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Slow booting
Kamil Kułaga writes: > > After init of soundcard and before swap activation i have 90 seconds > hole. Is it normal? Can I configure kernel to somewhat avoid this? Unfortunately, I think adding a large swap partition (yours is 6GB) can be a slow operation under Linux. Google for "slow swapon" and you'll see several complaints. One simple solution might be to try running "swapon" in the background in your startup scripts. That's what I do on my (Ubuntu) laptop (which is frequently rebooted and would pause for a significant amount of time waiting on its 3GB swap file otherwise). Note that, on a Lenny installation, "swapon" is run twice, in "/etc/init.d/checkroot.sh" and in "/etc/init.d/mountall.sh", so make sure you make the change in the right place. -- Kevin -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: Problem with removing a chroot
Ryan Klein <[EMAIL PROTECTED]> writes: > > I am having a problem removing the remains of a chroot; I used the > script in /usr/share/doc/libpam-chroot/examples/ and it created hard > links for the entire /proc folder in /var/chroot/user/testuser/proc/ > and I cannot remove it. Can someone let me know how to remove these > hard links so that I can remove /var/chroot/users/*? Actually, you've probably got another copy of "proc" mounted there. Try "umount /var/chroot/user/testuser/proc", and see if that fixes things up. It's not possible to create hardlinks across different filesystems, so in particular you can't create hardlinks to "/proc" files in your real filesystem. (Try it, and you'll get an "Invalid cross-device link" error or something similar.) -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: files encrypted with openssl enc?
"Douglas A. Tutty" <[EMAIL PROTECTED]> writes: > > Does anyone know if files encrypted with openssl's enc would be affected > by the openssl fiasco? Yes, there is an effect, though it may be of limited practical significance. If you used a strong passphrase and the CBC mode of encryption (e.g., "-aes-128-cbc" or "-aes128", which defaults to CBC), then your file should be safe. If you encrypted multiple files with the same passphrase, an attacker may be able to tell when the beginnings of two files match but should not be able to decrypt the files. The bug only affected random number generation, so for symmetric encryption, this should only affect the random salt used. The man page says that, by default, no salt is used, but that's wrong. By default, OpenSSL *does* use random salt. The bad OpenSSL would presumably have used salt from a limited set of possible values. This is still much better than using no salt at all, but not as good as using salt from the full set of intended values. The passphrase and salt are used together to produce the actual key and initial value (IV) for encryption. The main implications of using salt from a limited set are that: 1. It's more feasible for an attacker to perform precomputed attacks from a dictionary of passphrases. 2. It increases the chance that two files encrypted with the same passphrase will use the exact same key and IV. For point #1, it's not an issue for a targetted attack on a specific file. It might be worth some people's time to perform this type of precomputation if they're in the business of examining many OpenSSL encrypted files every day, but if you aren't presently worried about a visit from the NSA, I think there's little reason to worry about this. For point #2, *if* this happens (two different files encrypted with same key and IV), the impact depends on the block cipher mode used. If you used OFB mode (e.g., -aes-128-ofb), security is destroyed. If you used CFB, information about the first encrypted block (128-bits for "-aes-128-cfb") of the files may be leaked. Neither ECB nor CBC modes leak information in this manner. However, for any mode (including ECB or CBC), an attacker can tell if two encrypted files (using same key and IV) have the same beginning or not. And for ECB, the attacker can tell whether or not any two blocks are the same. This is a big problem if the attacker gets the plaintext of one of the files, because he can use it as a "dictionary" to decode blocks of the other file, regardless of where they appear. For CBC, the attacker is limited to determining if the beginnings of two files match. After the first difference in the files, he can't mount a useful attack. I hope that helps. You should probably double-check on an appropriate OpenSSL list or something if you're really concerned, though. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: openssl vulnerability and RSA keys
Ross Boylan <[EMAIL PROTECTED]> writes: > > The recent security advisory for Debian's version of openssl says that > you should regenerate all keys, and that DSA keys should be considered > compromised. > > Does this mean that RSA keys for openssh should not be considered > compromised? If so, why the need to regenerate them? To clarify, *all* SSH keys, whether DSA or RSA, generated using the bad version of OpenSSL are garbage: they are easily guessable. Furthermore, as I read the advisories and other sources, because of the way DSA keys are used, even strong DSA keys (generated by good versions of OpenSSL) are compromised if they were used locally with the bad OpenSSL. "Locally" here means that the strong DSA key was used on the same side of the connection as the bad OpenSSL: if you used a user DSA key to "ssh" to a remote server and your local OpenSSL library was bad, or if a server DSA key was used by "sshd" to accept a remote connection and the server's OpenSSL library was bad, then the respective key is compromised (even if it was a strong key generated by a good OpenSSL library). "Compromised" means that anyone who intercepted and saved such an SSH conversation can now use this new knowledge of the OpenSSL vulnerability to recover the private DSA key from the connection data. At least, that's how I've interpreted what I've heard. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Kind of OT] Why's this look like gibberish to me?
"Douglas A. Tutty" <[EMAIL PROTECTED]> writes:
>
> What about man aptitude? Under Command Line Options, the first line, I
> see:
> ... begin with a hyphen ("\fB-\fR")
>
> And, under "The following actions are available", each heading has the
> same thing, e.g.:
>
> \fBinstall\fR
This is definitely a bug, but not UTF-8 related: it renders this way
on my UTF-8 capable terminals, as well. It looks like it's already
documented in bug #438725 and fixed in testing, but we're stuck with
it in stable.
--
Kevin Buhr <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Kind of OT] Why's this look like gibberish to me?
"Douglas A. Tutty" <[EMAIL PROTECTED]> writes: >> >> The problem isn't the manpage author, it's your setup. >> >> Specifically, you're using a locale that sports UTF-8 encoding, but > > wrong. Lang=C. I don't have any locales installed. This is regular > stock VT (no fonts, etc). Well, let's put it this way. Create a text file named "test.1" containing the following: .TH TEST "1" .SH NAME test \- it's elementary Now, run "man -l test.1". Does your fontless, stock VT show an ASCII apostrophe or a little block? If it shows a block, your setup is broken, no matter what LANG is set to. If it shows an ASCII apostrophe, I would be grateful if you could send me the name of a stock Debian manpage that shows a block instead of an apostrophe (preferably with its owning package name and version, if you aren't using plain Etch). I would very much like to track down the problem and file bug reports on the offending manpages. Thanks. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Kind of OT] Why's this look like gibberish to me?
Chris Bannister <[EMAIL PROTECTED]> writes: > > Interesting, I have: > LANG=en_NZ.UTF-8 > and in /etc/console-tools/config > SCREEN_FONT=lat0-sun16 > With that setup, Dotan Cohen's line looks like solid black squares > separated by dashes. You mean this is happening on the Linux console, right? Your LANG setting is fine, but the "lat0-sun16" console font doesn't contain any Hebrew characters, so that's why you're getting solid black squares (indicating "no character available") separated by dashes. You can load a Hebrew font on the current console: consolechars -f iso08.f16.psf.gz and Dotan's list should show up fine, but then accented latin characters won't be available. I think without special support, the Linux console handles only 256 characters at once (or 512 if you're willing to give up bold text). You can use the "dynafont" package, which uses dynamic font loading tricks to allow displaying text that requires more code space than that. It comes with a font that includes about 7900 glyphs and does pretty well if you don't care about Asian language support. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Kind of OT] Why's this look like gibberish to me?
"Douglas A. Tutty" <[EMAIL PROTECTED]> writes: > > What gets me is when a man page is written in english and "'" gets > translated as "?", as in can?t or "'" is a square white blob (on a > regular VT). Why couldn't whoever wrote it in english have used the > standard english "'" glyph instead of a UTF thingy? The problem isn't the manpage author, it's your setup. Specifically, you're using a locale that sports UTF-8 encoding, but you're using a terminal/font combination that is not capable of correctly rendering UTF-8-encoded common typographical symbols used for English language text, like the right single quote / apostrophe. If you use a locale based on ASCII encoding instead, those manpages will render more correctly (for example, substituting the unsightly ASCII vertical apostrophe for its more urbane cousin or writing (C) in place of the copyright symbol). See the bottom of this post if LANG=C isn't good enough for you. Unlike some people here, I couldn't give a σθιτ if you, S. Keeling, or anyone else wants to use UTF-8 or not---I'm not on any crusade---but an environment variable setting of "LANG=en_US.UTF-8" is basically an announcement to applications that your terminal is UTF-8 capable. You don't have to run a UTF-8-capable terminal if you don't want to, but you shouldn't lie to your applications and then whine about those damn foreigners writing manpages incorrectly (just a joke, just a joke). In truth, if you look at the manpage source, you'll probably find that the manpage authors *have* used the ASCII "'" character for apostrophes and right single quotes. That's because this is the encoding convention used in the typesetting language "roff" in which manpages are written. You write `stuff like this' knowing that a correctly configured manpage rendering pipeline will convert those ASCII backticks and apostrophes into the correct English typographical symbols (if the manpage is being printed or being displayed on a sophisticated terminal) or at least do the best it can (if it's being delivered to an ASCII-only terminal). If manpage writers were really on the ball, they'd use \(lqleft and right double-quotes\(rq too, but you don't see too much of that. To clarify further, there's nothing English about "'". If it's anything, it's ASCII, not English. I'm not sure that the ASCII standard actually specifies what printable characters, including "'", are supposed to look like, but in most fonts with ASCII-compatible encoding, the "'" character is rendered as an undirected, typewriter-style apostrophe, like a vertical tickmark, and I believe this is pretty much universally accepted as the "correct" rendering of this character, among those who care about these things. In particular, it is *not* the character used in typeset English text as an apostrophe or right single quote. It's rarely used in English text at all, except in historically ASCII contents like email and computer plain text files. It's about as un-English as you can get. It's very ASCII, though. Anyway, to really take a stand on this UTF-8 crap and announce to the world that 7 bits were good enough for cavemen so, by God, they're good enough for you too, you can simply use a preexisting ASCII-only locale (like LANG=C) or you can generate one. Add this line to "/etc/locale.gen": en_US ANSI_X3.4-1968 run "/usr/sbin/locale-gen" as root, and find some way to set "LANG=en_US" or "LC_ALL=en_US". ANSI_X3.4-1968 is another name for ASCII, so your new "en_US" locale shouldn't bother you with heretical characters. Some applications will still give up and print a "?" for non-ASCII characters, but "man" should do an excellent job displaying a pure ASCII rendering of your manpages for you. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: iptables "whitelist" rule
Raven <[EMAIL PROTECTED]> writes: > > Now I want to be able to run the amuled daemon ON the debian router but > I am not really sure how to tell iptables to whitelist the traffic that > is not being forwarded. > In other words, the ipp2p module should not drop the packets originating > from/destinated to the router itself. [ . . . ] > # Block P2P > iptables -A FORWARD -m ipp2p --ipp2p -j DROP > iptables -A INPUT -m ipp2p --ipp2p -j DROP > iptables -A OUTPUT -m ipp2p --ipp2p -j DROP I haven't used "ipp2p" before, but if you delete the INPUT and OUTPUT rules and keep the FORWARD rule, I think that would do what you want. Packets to and from the amuled daemon (whether from the Internet, wireless nodes, or whatever) will pass through the INPUT and OUTPUT tables and be permitted, but P2P packets between wireless nodes and the big, bad Internet will pass through the FORWARD table and be dropped by the remaining rule. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to create an ssh chain A->B->C to do http over ssh across the chain?
Mitchell Laks <[EMAIL PROTECTED]> writes: > > Here is the situation. You have machines A->B->C. You want to create a ssh > tunnel directly > from A to C. > > Machine A can see machine B and machine B can see C, but A can't see C > directly. > A and B are on a local network and only B has 'limited net access'. I tested the following two solutions, and they seem to work. First, running the following on host A: hosta$ ssh -L 8080:localhost:8080 B ssh -D 8080 [EMAIL PROTECTED] will set things up so that localhost connections on A to port 8080 will be forwarded over an SSH connection to port 8080 on host B. The second "ssh" command running on B, meanwhile, will then act as a SOCKS server on port 8080, accepting connections forwarded from A, demultiplexing the SOCKS stream, and managing connections as if they originated from C. Note that you could do: hosta$ ssh -L 8080:localhost:8080 B ssh -N -D 8080 [EMAIL PROTECTED] (i.e., specifying the -N flag) instead, but I had trouble with the second "ssh" connection sticking around after the first died when I tested it, so the former might be better, even though it ties up a terminal. Note also that, using this method, other users on host B could also connect to local port 8080 and use that socks server to manage connections originating from host C. This may or may not be a problem. Second, another possibility, which may be more flexible, would be to set up an SSH tunnel from A to B to accomodate a direct SSH connection from A to C. That is, the command (run on host A): hosta$ ssh -NL 8022:C.com:22 B & will set things up so that local connections to port 8022 will be forwarded over the tunnel B to become a connection from B to port 22 on C. Now, if you run the command (on host A): hosta$ ssh -o UserKnownHostsFile=/dev/null \ >-o StrictHostKeyChecking=no -ND 8080 -p 8022 localhost that will connect to the SSH server on C providing a local SOCKS server on A. Note that the first SSH tunnel is being used only for its tunnelling side effect, not security. In fact, the traffic between B and C will travel "in the clear", but the traffic here is from the second SSH connection which is separately encrypted and so safe. The two "-o" options here are to prevent SSH from verifying and storing the host key for this connection. You are actually connecting to host C, but it looks to SSH like you are connecting to "localhost", so SSH will store C's host key as if it's the localhost key, and you'll get warnings and errors about changed keys in the future. This would open the door to a man-in-the-middle attack, but it's probably not a big concern for your purposes. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DCHP
Kevin Buhr <[EMAIL PROTECTED]> writes:
>
> and change it to this:
>
> iface eth0 inet manual
> up dhclient3 -lf /var/lib/dhcp3/dhclient.$IFACE.leases -pf
> /var/run/dhclient.$IFACE.pid $IFACE
> down kill $(< /var/run/dhclient.$IFACE.pid)
Whoops. One problem with this is that it doesn't actually bring the
interface down. I hadn't noticed before. You might want to add one
more line, like so, and I think that will work properly:
iface eth0 inet manual
up [same as above]
down kill $(< /var/run/dhclient.$IFACE.pid)
down ifconfig $IFACE down
--
Kevin Buhr <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DCHP
Cassiel <[EMAIL PROTECTED]> writes: > >Every time I restart my Lenny I obtain a new ip addr from one of the 2 >dhcp servers. We have a 1 month lease on this servers and this should >never happen within this period. >any experience on this? I'm assuming that your interfaces are automatically configured and deconfigured by the startup scripts and so implicitly by "ifup" and "ifdown" using the configuration in "/etc/network/interfaces". I'm also further assuming you have the "dhcp3-client" package installed. The "dhclient3" DHCP client in the "dhcp3-client" package is capable of reacquiring an old lease on reboot, but the reason it isn't working is because of an issue with the Debian "ifdown" program. It's hardcoded to run "dhclient3 -r ..." on interface shutdown. This causes "dhclient3" to release the lease and change the times in the "/var/lib/dhcp3/dhclient.xxx.leases" file to expire the lease before exiting. If it wasn't for this, "dhclient3" would happily try to reuse that lease after reboot. You can work around this by explicitly specifying commands to bring the interface up and down. Assuming the interface is "eth0", first bring it down with "ifdown eth0". Then, in "/etc/network/interfaces", find the clause for your interface, which will probably look like this: iface eth0 inet dhcp and change it to this: iface eth0 inet manual up dhclient3 -lf /var/lib/dhcp3/dhclient.$IFACE.leases -pf /var/run/dhclient.$IFACE.pid $IFACE down kill $(< /var/run/dhclient.$IFACE.pid) The "up" line here (make sure it's all one line) is the same as the internal version hardcoded into "ifup". The "down" line is changed to simply kill the old "dhclient3" instead of running "dhclient3 -r ..." as mentioned above. Now, do "ifup eth0" again. The first time, it'll allocate a new IP address. Make sure "dhclient3" is running. Now, try "ifdown eth0", and make sure "dhclient3" is no longer running. Finally, try "ifup eth0" again, and you'll hopefully get back your old IP address. Try rebooting, and---again---you should get back your old IP address. Good luck. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] how to clean grime off old computer MB?
"Douglas A. Tutty" <[EMAIL PROTECTED]> writes: > > I have a couple of new-to-me old computers. They've been well used in > what looks like a normal office environment and they're a bit grimey > inside; not just dust that blows away. I figure that I should clean > that off so the dust doesn't act like a thermal insulator but I'm unsure > what to use, since air alone isn't doing it. I don't want to remove > e.g. the CPU from its socket. (P-133, socket 7). As another take on the issue, there's also such a thing as leaving well enough alone. Provided the computers are working now, the most likely outcome of a good, thorough cleaning, is that they will work exactly as well as before. The second most likely outcome is that one or more will stop working, and you'll need to fiddle around for hours getting them working again. >From a thermal perspective, others may have better advice, but here's my take on it. Most components don't generate much heat and can dissipate most of it through leads soldered to the motherboard, so grime on their surface doesn't matter much here. As long as the motherboard isn't entirely caked with a layer of filth and as long as loose dust has been blown or dusted away so air can flow over the motherboard surface, it'll probably be fine. The components to worry about are any that have either a fan or a passive heatsink: these components are generating the most heat, and dust and grime are most likely to affect the operation of active or passive cooling systems. Note that the issue is less a coating of grime acting as a thermal insulator and more one of dust (dry or greasy) clogging the cooling fins so that air cannot flow through them. If the CPU, main chipset chips, and graphics chips have heatsinks and fans that are relatively free of dust and the metal components of the heatsink aren't entirely coated with grime, they'll probably cool just fine. (This assumes that the case fans and grills are clean, too.) Taking a dry toothbrush to the problem and tackling the biggest clumps without worrying too much about getting everything sparkling will probably be the safest and most useful approach. On the other hand, this is hardly valuable equipment, is it? If you want a cool war story to impress friend and relatives, then I believe Marty's suggestion is sound: I recall people on "sci.electronics.repair" claiming to have had good success putting circuit boards (stripped of socketed components) in the dishwasher. I'm not sure whether the dishwasher's heated dry cycle would be recommended, and I hadn't previously heard about the leakage problems with electrolytic capacitors that Russell mentioned. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: OMG! Think I did something stupid with dmcrypt
Andrew Henry <[EMAIL PROTECTED]> writes: > > I have debian lenny on a server with full disk encryption (the guided > partitioning option) and an external usb WD Mybook that is also > encrypted with dmcrypt/LUKS. LUKS stores the encrypted master key (generally decryptable by supplying just the passphrase, though it's possible for a keyfile to be used) in a header at the start of the partition. So, you probably haven't lost your data. But why are we talking about this? Have you tried sticking your bloody USB stick in a Linux machine and mounting the partition? If you need to do it manually: cryptsetup luksOpen /dev/sda1 mydata ...enter passphrase when prompted... mount /dev/mapper/mydata /mnt ls /mnt where "/dev/sda1" is the partition. Good luck! -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How to work with portable mail server?
Jabka Atu <[EMAIL PROTECTED]> writes: > > is there a way to use exim to get mails also from the net ? > > Althow i know that it can be done using 24 working server that uses > dyndns / no-ip etc. > > but what about when my mail server is on a laptop that can be offline > for 10-12 hours or even days. You pretty much need an "always up" mail server to accept your mail, because that's just how Internet mail works. Mail will be sent to your server at random times (not long after the sender clicks "Send") and---where it fails---retried according to the sender's schedule (i.e., according to the configuration of the sender's outgoing mailhost, typically) which you can't control. If your laptop really was online at least 12 hours a day, you might eventually receive most of your mail (some on first try, some on retries), but it's really a crapshoot, and there would be all sorts of problems. Many senders would receive those unsettling messages about "temporary failure - no need to resend" that always result in the unschooled resending an additional copy anyway and then calling you on the phone to make sure you got it. High-traffic mailing lists wouldn't work: most will give up after a few failed messages and send you a note asking you for manual confirmation to restart. And if there were a couple of days that you couldn't get your laptop online or could only get it online for a couple of hours, you'd probably lose a chunk of mail. > is there any way to halt the messages any where ? The way to halt the messages is to have an "always up" mail server accept them for you. This may be your 24-hour home server, it may be an ISP server, it may be a mail hosting service's server, or whatever. Then, you use "fetchmail" to get the mail onto your laptop and delivered through your local copy of "exim". If you don't like your ISP and/or want to use your own domain name and your ISP won't cooperate, mail hosting services are cheap (say $10/year) if you just need a modest amount of POPpable storage and an outgoing relay. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Dbus, Hald Groups?
David Baron <[EMAIL PROTECTED]> writes: > > Dbus is running in the 111 "crontab" group! > Hal is running in the 127 "boinc" Are! Note that "ps", by default, displays process *users*, not groups. For "dbus" and "hal", the correct users are "messagebus" and "haldaemon". Since these names are unusually long, "ps" will display them as numbers instead of names, but you need to look them up in "/etc/passwd", not "/etc/group", since the user ids and corresponding group ids won't necessarily match. These numbers aren't fixed---they will differ from system to system, depending on the exact order packages were installed. For example, on one of my machines, the user ids are 102 and 107; on another, they are 104 and 108. If you double-check and "dbus" and "hal" *really* are running as the wrong users, then---assuming a reboot doesn't fix the problem---it might be the case that you have multiple users in "passwd" with the same userid. This shouldn't happen, but you can probably fix the damage by changing the "messagebus" and "haldaemon" numbers to something that isn't used and rebooting (but make a backup of "passwd" first in case things go horribly wrong). In general, renumbering userids like this won't work very well, because file ownership is stored by number, not name, and renumbering will screw that up. I don't believe that "messagebus" and "haldaemon" own any files, though, so this probably won't be a problem. > To access these, do I need to be a "member" of these groups? This > could be why kde4 seems to need root privileges to start a session! You do not need to be a member of the "messagebus" or "haldaemon" groups to start a KDE session, so the problem must be something else. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: su doesn't work "Authentication failure"
"Dennis G. Wicks" <[EMAIL PROTECTED]> writes: > > Kevin Buhr wrote the following on 01/31/2008 12:50 PM: > > From aptitude show login ==>> 1:4.0.18.1-7 <<== >> should give: >> >> 1381ae1ac77b512258657b096522bb6a /bin/su >c80fc747e24fa8bfa099cbef0bfb926f /bin/su <<== > from md5sum /bin/su > >> If your Etch version matches mine but the md5 doesn't, you might start >> to get pretty worried. Dennis, I posted a followup message but you might have missed it. I was sloppy: the 1381... hash I posted was for the amd64 architecture; the c80f... hash you list matches what should be expected for i386, so there's no problem with your copy of "/bin/su". > What should I be worried about and start looking for? Since yours *does* match, you don't have any worries. More generally, though, in the normal course of events, files (other than configuration files and the like) installed on your system should match the version in the appropriate Debian package. A hash mismatch just means the files don't match. There are many possible explanations for this, most of them innocent: 1. First, as we encountered above, the package version, architecture, or official source of the package might not match precisely. When I say "official source", the main Debian archive and any of its mirrors would be considered a single source, so all should have precisely matching packages. On the other hand, if you install packages you've compiled from source or gotten from a "backports" site or from a derivative distribution (Ubuntu, etc.), a mismatch is likely occur even with a perfect version/architecture match. 2. The file might be a "special" file that gets modified on installation. Configuration files in "/etc" for example will frequently differ from the source, even when a package is freshly installed. 3. The file might have been intentionally modified by the system administrator. 4. The file might have become corrupted. 5. The file might have been installed from original installation media whose copy didn't precisely match the file in the official package and no later version of the package has ever been installed. 6. The file might have been tampered with by someone who broke into your system. 7. You may have somehow been tricked into installing a malicious version of the package. These are probably in roughly the order of likelihood, so I should have tried harder not to sound alarmist, since the ones to worry about are way down at the bottom of the list. For "/bin/su", a mismatch is cause for immediate suspicion (especially if, as seemed to be the case for the original poster, something weird is going on with that file anyway) simply because it's a security-sensitive utility that is a frequent target for rootkits and the like. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: su doesn't work "Authentication failure"
Kevin Buhr <[EMAIL PROTECTED]> writes: > > If your version of the "login" package is the latest official Etch > version 1:4.0.18.1-7, then "md5sum /bin/su" should give: > > 1381ae1ac77b512258657b096522bb6a /bin/su Sorry. That was sloppy of me. The above hash is for the amd64 architecture. The md5sum for the i386 architecture should be: c80fc747e24fa8bfa099cbef0bfb926f /bin/su -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: su doesn't work "Authentication failure"
paul <[EMAIL PROTECTED]> writes: > > It is possible to do 'su someuser' from root but it's not possible to > get back to root then using just 'su' or change from a normal user to > another user account. [ . . . ] > Jan 31 15:44:18 myserver su[27729]: (pam_unix) authentication failure; > logname= uid=1000 euid=1000 tty=pts/4 ruser=myuser rhost= user=root The "euid=1000" should read "euid=0": your "su" is running as the invoking user, so it fails for non-root users. The most likely explanation is that "/bin/su" doesn't have the setuid flag set, so that would be the first thing to check. (If the setuid bit *is* set, the problem may be that your root partition has been mounted with the "nosuid" mount flag or something.) If you have a logical explanation for the missing bit, great, otherwise good security practice would suggest that you give a little thought before restoring setuid bits on files where it has mysteriously disappeared. If your version of the "login" package is the latest official Etch version 1:4.0.18.1-7, then "md5sum /bin/su" should give: 1381ae1ac77b512258657b096522bb6a /bin/su If your Etch version matches mine but the md5 doesn't, you might start to get pretty worried. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: exim - what is it? (how does it run)
"Bob Goldberg" <[EMAIL PROTECTED]> writes:
>
>What exactly IS exim?
>IOW: when I setup sendmail, I'm working with bash scripts.
>when I setup an exim conf file - what exactly runs it? perl?
The exim configuration file is written in an Exim-specific language
parsed by nothing but Exim. It is documented in the Exim manual,
though not always very well. General syntax is documented in the
section "The Exim run time configuration file" or "The Exim
configuration file", documentation on the "${lookup...}" expansion is
available in the section "String expansions", and specific types of
lookups are documented in the section "File and database lookups".
The general syntax for a "lookup" is:
${lookup{key}lookuptype{On success}{On failure}}
So, for your example,
data = [EMAIL PROTECTED]/etc/exim4/email-accept}
{:fail: User unknown }}
your {:fail: User unknown} block is being expanded on *success*. That
is, this code looks up the expansion of "[EMAIL PROTECTED]" in
"/etc/exim4/email-accept", and---if it is found---sets data to ":fail:
User unknown", which is exactly the opposite of what you want.
This is probably being used in a "redirect" router. If the sole
purpose of this router is to reject email addresses that don't appear
in "email-accept", then:
data = [EMAIL PROTECTED]/etc/exim4/email-accept}
{}{:fail: User unknown }}
might work. Now, if the lookup succeeds, the data is set to the empty
string, and the router will decline to process the address, leaving it
for a different router (to deliver, for example). If the lookup
fails, the router will process a :fail: redirect with the given error
message.
Taking a step back, though, I'm not so sure writing your own Exim file
from scratch, as you seem to be doing, is the best way to get Exim
"working". It's much easier to start with a barebones configuration,
such as one of the stock configurations generated by Debian, and tweak
that as necessary.
--
Kevin Buhr <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Email programs that work.
Michelle Konzack <[EMAIL PROTECTED]> writes: > >> Still, there are some unpleasant problems I couldn't solve. The worst >> one was that Mutt downloads the whole message. That is, it does not >> support selective retrieval of MIME parts, AFAIU. > > I do not know one single IMAP client which can do this... > Even under Windows Thunderbird 1.5 does. Non-inline attachments over 3 bytes should be downloaded only on demand, provided the server supports it. Inline attachments get downloaded no matter how big they are, unfortunately. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use of dpkg --set-selections is brain-dead?
"Michael S. Peek" <[EMAIL PROTECTED]> writes: > > Which begs the question: Why doesn't 'apt-get dselect-upgrade' install > the package? Does your package have any unsatisfied dependencies? They need to be scheduled for install via "dselect --set-selections", too. If you're going to go this route, you have to do all the dependency resolution manually. This is an intentional design feature, so you can "Q" out of "dselect"'s Select step with unresolved dependencies and still have the Install step install the packages whose dependencies you *have* resolved. If you want to install packages with automatic dependency resolution from the command line, then "apt-get install x y z" (or "aptitude install x y z") would normally be the way to go. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use of dpkg --set-selections is brain-dead?
"Mumia W." <[EMAIL PROTECTED]> writes: > > The man-page for dpkg suggests that Michael's method should have > worked: > >> dpkg --set-selections >>Set package selections using file read from stdin. > > Notice that additional parameters are not required, and the input > comes from stdin. I was talking about "dpkg --get-selections", not "dpkg --set-selections". To be more explicit, "3dchess" is currently purged from my system. Now, watch and be amazed: # dpkg --get-selections | egrep 3dchess # dpkg --get-selections 3dchess 3dchess purge # echo '3dchess install' | dpkg --set-selections # dpkg --get-selections | egrep 3dchess # dpkg --get-selections 3dchess 3dchess install # You'll note that, even after "3dchess" has been selected for installation, it will not be listed by: dpkg --get-selections because that doesn't list purged packages, even ones ready to be installed. Instead, you must instead explicitly write: dpkg --get-selections 3dchess to verify that the selection status of this package has changed. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Use of dpkg --set-selections is brain-dead?
"Michael S. Peek" <[EMAIL PROTECTED]> writes: > > I've traced my problem down to the use of 'dpkg --set-selections' > command. As an example, I have a package named tiem-nis-client-cfg > that sets up NIS for generic workstations. If I understand correctly, > I should be able to do the following: > >echo "tiem-nis-client-cfg install" | dpkg --set-selections > > And then, when I type 'dpkg --get-selections', I should see > "tiem-nis-client-cfg install" one some line in the output. No, "dpkg --get-selections" without further arguments only lists packages that are either installed or deinstalled (but still have their config files on the system), not purged packages or those that have never been on your system, even if those packages have been selected for installation. If you run: dpkg --get-selections tiem-nis-client-cfg that should show that your new package has been selected for installation. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Sourceforge lists and Return-Path header
Kevin Buhr <[EMAIL PROTECTED]> writes: > > The final alternative is to employ ugly per-MUA hacks, like the > "use_from" Mutt option that Andrew mentioned. Whoops... It looks like Andrew's descriptions were a little mixed up. According to the Mutt manual, it isn't "use_from" that does this, it's "envelope_from". That is, setting "envelope_from" will derive the envelope sender from the "From" address and pass it to "sendmail" via the "-f" option, so *that* would be the ugly hack you'd want, if you like ugly hacks. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Sourceforge lists and Return-Path header
"Roberto C. Sanchez" <[EMAIL PROTECTED]> writes: > > When I send from thunderbird from any machine, it works as it is > connecting directly to santiago. If I use mutt on santiago, it works > fine there as well since it is running an instance of Postfix which can > be reached from the public internet. My question is this, is my setup > broken (mutt/postfix/smarthost) or is sourceforge's setup broken? It looks like *your* setup. Your return path (AKA envelope sender) must be routable. That's how remote mailers get bounces back to you, for one thing. If "santiago" is or can be set up to accept mail for "miami" as local mail (i.e., "miami.connexer.com" or "*.connexer.com" is listed in "santiago"'s "Other destinations to accept mail for?" in Debian Postfix configuration parlance), then all you're missing is the MX record for "miami" pointing to "santiago": miami.connexer.com MX 0 santiago.connexer.com If you can't or don't want to do this, you should either reconfigure Postfix on "miami" to rewrite the envelope sender as if the mail originated from "santiago", or reconfigure Postfix on "santiago" to do the rewriting, at least on email that leaves your private domain. The final alternative is to employ ugly per-MUA hacks, like the "use_from" Mutt option that Andrew mentioned. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Weird cursor problem in X11
Jacob S <[EMAIL PROTECTED]> writes: > > Both in gdm and after logging into an x session, a copy of the mouse > pointer will 'freeze' in one spot on the screen. The usual blanket solution for X cursor problems is to try disabling the hardware cursor. Try adding: Option "SWcursor" "on" to the "Driver" (or "Screen" or "Monitor"---any of these should work) section of your "XF86Config-4". -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Where's the grub boot menu?
Jacob, Is it possible that GRUB is looking for "/boot/boot/grub/menu.lst", instead of "/boot/grub/menu.lst"? The "README" makes reference to this when "/boot" is a separate partition. When you ran "grub-install", did it not create a "/boot/boot/grub" directory with a "menu.lst" template in there? If so, GRUB is probably using that one instead of the one you've been modifying. The "update-grub" script, unfortunately, only updates the first of "/boot/grub" and "/boot/boot/grub" that it finds, so it won't have touched the version that GRUB is using, if this is the case. The only difference I see between our "menu.lst" files is that my Xen boot stanzas have no "root" line in mine: title Xen 3.0 running 2.6.16.2-xen-amd64-k8 kernel /xen-3.0-amd64.gz dom0_mem=262144 module /vmlinuz-2.6.16-2-xen-amd64-k8 root=/dev/mapper/main-buddharoot ro console=tty0 module /initrd.img-2.6.16-2-xen-amd64-k8 savedefault boot However, I doubt your problem has anything to do with problems in the "menu.lst"---it seems pretty clear that GRUB is just failing to find the file entirely or using a different copy. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Making a mixed audio and data CD with cdrecord?
Adam Funk <[EMAIL PROTECTED]> writes: > > I'd like to make a mixed audio and data CD that can be played in a > normal audio CD player or mounted on a GNU/Linux or Windows box. What you're trying to create is sometimes called a "CDplus" or "CD+" disc. These are multisession discs with an initial audio session followed by a data session. Normal audio players don't recognize multisession discs, so they just read the first (audio) session. Such discs need to be written in two "cdrecord" passes, using something like this: cdrecord -v dev=/dev/hdd -multi -pad -audio track1.wav track2.wav track3.wav mkisofs -r -J -C `cdrecord -msinfo dev=/dev/hdd` -M /dev/hdd -o foo.iso data/ cdrecord -v dev=/dev/hdd -data foo.iso Obviously, it'd be a good idea to create a test CD-RW first, assuming your audio player reads CD-RWs okay. Googling for <> and < may help, too. In particular, there's a "README.cdplus" floating around that gives instructions on creating these kinds of discs. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Firefox question about pop-up menus; (solved?) and a new annoyance
Paul E Condon <[EMAIL PROTECTED]> writes: > > Then the mozilla extension installer worked, *but* the new image of > firefox has a problem that is in its own internal configuration. It > is most noticeable in the top line of buttons (File Edit View > ...). When I click on any of these it becomes 'highlighted' by > changing the backgound from gray to white and the foreground lettering > from black to white. This is a known problem with Firefox 1.0.x's interaction with Debian's version of the Gnome "Simple" theme. See the Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=257430 It's fixed in Firefox 1.5 (and the above bug report includes a backport of the fix), but that's of little help if you want to use the official Debian package without compiling your own. Fortunately, there is a reasonably straightforward workaround. From your Gnome menu, select "Applications -> Desktop Preferences -> Themes", and pick just about any theme other than "Simple". "Crux" and "Default" look about the same as "Simple", and if I recall correctly neither of them exhibits the problem. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: df discrepencies
charlie derr <[EMAIL PROTECTED]> writes:
>
> Thanks Kent, Liam and Martin for the quick responses. I wasn't
> entirely clear on the situation -- the machine didn't always show this
> discrepency, so I don't think it's due to the "system overhead" sort
> of thing.
Charlie,
Martin's got it right. By default, 5% of the disk is reserved for use
by processes running as "root", probably including your "rsync"
scripts. The fourth column of the "df" output, on the other hand,
reports the free space available to regular users.
This reserved space business is documented in the "mke2fs" manpage
(see the "-m" option), and the size of the reserved portion can be
changed on an existing filesystem with "tune2fs" and specified either
as a percentage ("-m") or a raw number of blocks ("-r").
In particular, you can use "tune2fs" to set it to zero, and the
columns of "df" output will be consistent, but you probably shouldn't.
In addition to providing a little bit of slack space for processes
running as root to continue functioning when the disk fills up,
keeping some small percentage of the disk free helps reduce the
severity of fragmentation that would otherwise occur if the disk was
to fill up completely (and that could then remain even when space was
subsequently freed).
Reducing it to 1% should be fine, though.
> I am absolutely certain that in the past I've seen output similar to
> the following:
>
> /dev/sda1 440G 431G 9G 98%
I don't think you would have seen this on an ext2 or ext3 filesystem,
unless you explicitly created one with no reserved space. The default
has been 5% as long as I can remember.
> and over time, this "degrades" to the present situation -- it does
> appear to me that the 2nd and 3rd columns are definitive (and that the
> 4th column is in error) because the rsync scripts that ran last night
> all seemed to succeed in writing to this partition despite the fact
> that column 4 was reporting 0 as the available disk space.
Again, writes as a normal user probably would have failed, but an
"rsync" running as "root" would have continued writing to the reserved
space.
--
Kevin Buhr <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: what is the stack size in Debian kernels?
"H.S." <[EMAIL PROTECTED]> writes: > > This may be a dumb questions, but how do I find what stack size that my > Debian kernel (2.6.12) has? More generally, how do I determine the stack > size of any running Linux kernel? Is there an option in the .config file > that determins the stack size? As others have pointed out, for the i386 architecture, there are only two stack sizes available in the "normal" kernel. 8K is the default, but there is a CONFIG_4KSTACKS configuration variable that changes it to 4K (but uses a separate stack for interrupt handling to partially compensate). Debian kernel-image packages don't normally have the "/proc/config.gz" feature enabled, but they should install a copy of the ".config" used to build the kernel in a "/boot/config-*" file, and no stock Debian kernels have this variable set, as far as I know, so the Debian stack should be the default of 8k. A patch to add a 16k stacks option that *also* uses a separate interrupt-handling stack to give even more free space is available at: http://www.linuxant.com/driverloader/wlan/full/archive/linux-2.6.12-16kstacks.patch -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Mozilla Firefox Menus
Carl Fink <[EMAIL PROTECTED]> writes: > > Submit a bug. I don't care if it DOES come from upstream, it's a bug. At > the least, a bug existing would mean that apt-listbugs and apt-listchanges > would notify people to change themes. It looks like it's already submitted as Debian bug #257430. A fix is already in the Mozilla trunk (see Mozilla bugs 251492 and 244955 for reference), but it won't be fixed in the Firefox/Thunderbird 1.0.x branch, so an upstream fix will have to wait until 1.5.x. I'm currently testing a backport of the patch to 1.0.x, and I'll attach it to Debian bug #257430 when it's tested; I don't know if the maintainer will want to apply it or not. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Any package on Debian to convert a WAVE file into MP3?
Rishi <[EMAIL PROTECTED]> writes: > > This is the output of the 'file' command which I guess indicates the > type of audio file format. > > --- > rec02.wav: RIFF (little-endian) data, WAVE audio, IMA ADPCM, mono 8000 Hz > --- > > When I run lame to convert it into MP3 it gives this error and proceeds. > > --- > Warning: corrupt or unsupported WAVE format > Assuming raw pcm input file > --- It appears that "lame" doesn't support the IMA ADPCM format. Instead of first converting to OGG and then to MP3 (which will produce a poor quality result), you can use SoX to convert the WAVE file to a new WAVE format that "lame" supports: $ file test.wav test.wav: RIFF (little-endian) data, WAVE audio, IMA ADPCM, mono 8000 Hz $ sox test.wav -s test2.wav $ file test2.wav test2.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 8000 Hz $ lame test2.wav test.mp3 [ . . . ] $ -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [Bit OT]: Latex Gurus?
"Byron Hillis" <[EMAIL PROTECTED]> writes:
>
> A quick Q for a Latex document layout. I want a single
> column output, but on the right hand side I want a line
> that separates the \marginpar notes from the rest of the
> text. Like this
>
> Body Text Body Text Body Text |
> Body Text Body Text Body Text |
> Body Text Body Text Body Text | MarginPar
> Body Text Body Text Body Text |
The following should do what you want and doesn't require any special
LaTeX packages. You can adjust the \marginrulewidth and \marginparsep
parameters at the top: the \marginparsep is the separation between the
text and marginpars, and a rule of width \marginrulewidth will be
placed in the middle of that separation.
-START OF EXAMPLE-
\documentclass{article}
\makeatletter
\newlength\marginrulewidth
\marginrulewidth=0.4pt
\marginparsep=3em
[EMAIL PROTECTED]
[EMAIL PROTECTED]@[EMAIL PROTECTED]
\kern.5\marginparsep\kern-.5\marginrulewidth
\vrule width\marginrulewidth
\kern.5\marginparsep\kern-.5\marginrulewidth}}\oldoutputpage}
\makeatother
\begin{document}
\noindent
Body Text Body Text Body Text Body Text Body Text Body Text Body Text
Body Text Body Text Body Text Body Text Body Text Body Text Body Text%
\marginpar{Marginpar}
Body Text Body Text Body Text Body Text Body Text Body Text Body Text
Body Text Body Text Body Text Body Text Body Text Body Text Body Text
Body Text Body Text Body Text Body Text
\end{document}
-END OF EXAMPLE-
--
Kevin Buhr <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: CPU fans shut off by Debian?
Stephen Lokitz <[EMAIL PROTECTED]> writes: > > I am running Sarge 2.4.27-2-686-smp on an intel SR1435VP2(which is > a 1U server platform) with dual 2.8 Xeon processors. I am required to > run the 2.4 kernel for my application. What appears to happen is that at > some random time after power on (~6-20 hrs), the cpu fans shut off which > causes the system to overheat and shut down. Stephen: Assuming the fans are plugged in via standard 3-pin cables to the motherboard, have you considered the low-tech solution of getting a couple of Y-adapters of the kind shown here: http://www.endpcnoise.com/cgi-bin/e/3-PINto4-PIN.html and plugging the fans into the "dumb" 4-pin power supply so they never shut off? If you want to monitor the fan speed (but still stop the BIOS from trying to control it), you can get the variation shown here: http://www.xpcgear.com/3to4pinycabw.html which has the additional advantage that it's a little more compact. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DNS lookup problems.
Christopher Rueber <[EMAIL PROTECTED]> writes: > > Okay, I've been looking for an answer for this for a little while, and > have been unable to find one. Here's the problem: Have you tried to Google for: dns actiontec "1.0.0.0" It looks like a common issue with the Actiontec 701 modem. In particular, see: http://www.dslreports.com/forum/remark,11430965 for some suggested solutions. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Internet (Once and for all)
"David R. Litwin" <[EMAIL PROTECTED]> writes: > > When I use the script /usr/local/bin/start-pppoe (one of the scripts > that is part of the software), it says no sir; eth0 still > broadcasting. I'm assuming the error message that appears on your screen is *not*: no sir; eth0 still broadcasting so what is the exact message you are seeing? > There is also a mysterious inet6 under both the lo (local loopback) > and the eth0. How do I get rid of this? This should be harmless, but on the off chance that it's causing problems, you can use: ifconfig eth0 del xxx/nn with "xxx/nn" replaced with whatever's listed as the inet6 address for that interface. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Background question
"M. Maas" <[EMAIL PROTECTED]> writes: > > Between the boot splash and the graphical login manager, there is a > screen with a black and white checkerd background and a big black > "X" which is the mouse. There's a barely documented command line option on recent X servers. If you pass "-br" (short for "black root") to the X server, the root window will come up solid black instead of the stippled checkerboard you're seeing. The exact mechanics of passing "-br" to your X server will depend on which login manager you're using, of course. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: DHCP questions...
"Kevin Wang" <[EMAIL PROTECTED]> writes: > > Second, where or how to check if the lease of DHCP expires? I know "ipconfig > /all" can do this under Windows. Information about your leases is probably stored in the textfile "/var/lib/dhcp/dhclient.leases" (or maybe "/var/run/dhclient.eth0.leases", depending on your configuration). There may be several unexpired leases there, only one of which you're using. Generally, if you do: egrep expire /var/lib/dhcp/dhclient.leases to list all the expiry times, the last (both the last displayed and the latest date) will be when your current lease expires. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On the verge of suicide:tar & gunzip problems
Vittorio <[EMAIL PROTECTED]> writes:
>
>> zcat /mnt/backup-compaq/home.tar.gz |
>> perl -ne 'm,home/vic/, && do { ++$count[($l + length($`)) % 512] };
>> $l += length($_); END { for (0..511) { printf "%3d %5d\n", $_,
>> $count[$_] if $count[$_] } }' | sort -nr +1 | head -20
>
> For the time being I've pit aside tghe idea of suicide but the complex program
> you suggested (see above) doesn't work. I put it inside an executable file
> and try to execute but It invariably says
>
> cannot execute binary file
Well, for some weird reason, it looks like you've introduced a bunch
of 0xA0 characters at the beginning of each line in your version that
weren't in my original. Also, it isn't meant to be pasted as 4 lines
into a file but pasted as 1 single, very long line at a Bash command
prompt.
Anyway, let's try it a different way. I've put a Perl program here:
http://www3.telus.net/buhr/misc/find_offset.pl
You can save this and then run the following command at a shell
prompt:
zcat yourtar.gz | perl find_offset.pl home/vic/ | head -20
--
Kevin <[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Do I *have* to have xauth (and all that it brings in?)
Bill Moseley <[EMAIL PROTECTED]> writes: > > But, I have a case where I need to first ssh to a machine on a public > IP and then from there ssh into the machine on the local LAN where I > want to run the application. If you don't mind the overhead of double-encrypting, you can tunnel SSH over SSH. If the public machine is "pubhost" and it knows the machine on which you want to run the application as "apphost", then start with the following on your machine: yourhost% ssh -f pubhost -L 8022:apphost:22 sleep 60 and, within 60 seconds, run: yourhost% ssh -o UserKnownHostsFile=/dev/null -X localhost -p 8022 This will establish an X11-tunnelling SSH connection to "apphost" over the previous SSH tunnel, so any password or passphrase you're prompted for will be whatever you'd use on "apphost". The "-o UserKnownHostsFile=/dev/null" option is to avoid checking (or adding) a bogus entry for "localhost" (with the public key of "apphost") to your "~/.ssh/known_hosts" file. Note that packets sent across this connection are encrypted on "yourhost" by the second SSH command, then reencrypted on "yourhost" by the first SSH command for transmission across the tunnel. On the other side, "pubhost" decrypts the latter layer of encryption and passes the packets on to "apphost" which decrypts the former layer. "yourhost" has to do double duty, but no packets are passed in the clear. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: On the verge of suicide:tar & gunzip problems
[EMAIL PROTECTED] writes:
>
> vic:/# tar -xvzf /mnt/backup-compaq/home.tar.gz
> home/
> home/victor/
> home/victor/.R/
> home/victor/.R/help.db
> tar: Skipping to next header
> tar: Archive contains obsolescent base-64 headers
>
> vic:/# gunzip /mnt/backup-compaq/home.tar.gz
> gunzip: /mnt/backup-compaq/home.tar.gz: invalid compressed data--crc error
> gunzip: /mnt/backup-compaq/home.tar.gz: invalid compressed data--length error
> vic:/#
Vittorio:
Don't kill yourself quite yet. These are the usual symptoms of
corruption in the middle of a gzip-compressed archive. If it was only
a couple of corrupt blocks, you have a pretty good chance of
recovering most of your data.
"zcat" will happily plow through the corrupt compressed file and
generate uncompressed text as best it can. Because of the nature of
the compression algorithm, a single bad compressed input block will
result in a long string of corrupt uncompressed output blocks.
Eventually, the decompression state will probably resynchronize
(though this is not 100% guaranteed, it'll probably happen within a
few hundred kilobytes). Assuming this happens, "zcat" will start
generating good output again.
The trouble is, the output won't generally be properly aligned, so
"tar" (which started skipping 512-byte blocks at the first bad header)
won't find another header aligned at the start of a 512-byte block,
and will gobble up the whole file without finding anything else to
untar.
So, how do you realign?
Well, assuming most of the files in your tarfile are from the
"home/vic/" directory, every header block will start with the string
"home/vic/". You can run the following one-liner:
zcat /mnt/backup-compaq/home.tar.gz |
perl -ne 'm,home/vic/, && do { ++$count[($l + length($`)) % 512] };
$l += length($_); END { for (0..511) { printf "%3d %5d\n", $_,
$count[$_] if $count[$_] } }' | sort -nr +1 | head -20
(I've formatted it onto multiple lines, but it should be typed in as a
single line.) This simply counts the number of times the string
"home/vic/" appears in the file at each possible offset within a
512-byte block. It outputs, at most, the 20 most frequent offsets.
For a small, corrupt tarfile, the output might look like:
165 291
027
18 2
398 1
The left column list the offsets; the right column gives the count of
each offset.
This indicates that the string appeared 291 times at offset 165, 27
times at offset 0, and a handful of times at offsets 18 and 398.
These last two are false positives (occurrences of "home/vic/" that
weren't from a tar header). The 27 occurrences of 0 are the headers
before the corruption. After the corruption, when the decompressed
stream recovered, it was offset by 165 bytes, and those 291 other
headers are recovered files at the wrong offset.
When you do this (since your tarfile is so gigantic), you'll probably
have a good number of false positives. However, if there was
corruption in only one place, there should be one non-zero offset that
is overwhelmingly more frequent than the rest.
Anyway, to recover files at a particular offset, for example offset
165, use the following:
zcat /mnt/backup-compaq/home.tar.gz | tail -c +166 | tar tvf -
Note that the number in the "tail" command should be one more than the
offset output by the one-liner.
Good luck!
--
Kevin <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Enabling telnet access
Paal Marker <[EMAIL PROTECTED]> writes: > > When telneting the box I get into the login, asked for username. When > entering a valid username I get this message: > "System bootup in progress -please wait" You probably have an "/etc/nologin" file (containing this text you see) that wasn't deleted by the bootscripts. The presence of this file is supposed to prevent *any* non-root logins. (See the nologin(5) manpage.) Any chance you're running this machine in single-user mode or in some other nonstandard configuration? Assuming the standard runlevel (number 2) and standard Debian startup scripts, the "/etc/nologin" file should have been removed by "/etc/rc2.d/S99rmnologin" link to "/etc/init.d/rmnologin". -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Computer shut down unexpectedly while unattended.
Adam Funk <[EMAIL PROTECTED]> writes: > > When I got up this morning I found that my computer had > mysteriously powered down overnight around 02:50. There's nothing the least bit suspicious in the logs you gave. It was probably just a power outage. Do you have any reason to believe it was something else? > Here are are the last log entries before it happened. If you really want to know what caused them... > /var/log/syslog > Mar 10 02:30:01 garcia /USR/SBIN/CRON[23159]: (root) CMD (test -x > /usr/lib/atsar/atsa1 && /usr/lib/atsar/atsa1) > Mar 10 02:40:01 garcia /USR/SBIN/CRON[23166]: (root) CMD (test -x > /usr/lib/atsar/atsa1 && /usr/lib/atsar/atsa1) > Mar 10 02:40:01 garcia /USR/SBIN/CRON[23167]: (root) CMD (nice -7 > /usr/local/exim/bin/exim -q) > Mar 10 02:50:01 garcia /USR/SBIN/CRON[23173]: (root) CMD (test -x > /usr/lib/atsar/atsa1 && /usr/lib/atsar/atsa1) Cron ran four jobs as root because: 1. You have "atsar" installed. I've never used it, but judging from the package description, it's no surprise that it runs periodically to collect system performance information. 2. You have a custom Exim installion. The above line is the usual, periodic queue run to retry sending messages that have temporary delivery failures. > /var/log/messages > Mar 10 01:50:46 garcia -- MARK -- > Mar 10 02:10:46 garcia -- MARK -- > Mar 10 02:30:46 garcia -- MARK -- These lines are inserted by "syslogd". It's just to ensure a regular message gets written to "messages". > /var/log/auth.log > Mar 10 02:40:01 garcia cron(pam_unix)[23165]: session closed for user root > Mar 10 02:50:01 garcia cron(pam_unix)[23172]: session opened for user root by (uid=0) > Mar 10 02:50:01 garcia cron(pam_unix)[23172]: session closed for user root These are normal. Cron generates these messages when it's running jobs as root. These specific messages correspond to cron running the "atsar" and Exim cron jobs mentioned above. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unexplained network problems
Marty Landman <[EMAIL PROTECTED]> writes: > >> I now see that the driver only writes information about transmission >> errors when its debug flag is set higher than the >>default. > > Where do you see that Kevin? And since I suspect an ongoing problem > would it make sense for me to change this to possibly capture more > errors than now, and if so, how? I meant I saw it while looking at the Tulip driver source. If you load the driver with "tulip_debug" set to 2, it should log transmit errors. (However, it may also log lots of other stuff, too, which could slow things down or fill your logs.) Here's how to unload and reload the driver with a different tulip_debug setting: ifdown eth0 rmmod tulip modprobe tulip tulip_debug=2 ifup eth0 There's no guarantee that the resulting log will actually tell you anything useful, however. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian Slow?
<[EMAIL PROTECTED]> writes: > > I'm guessing it has something to do with the memory usage, because > the machines here use about 15 MB of swap, with 20ish MB of memory > free by the time I'm halfway through my 1 GB swap at home! I've > cleaned up the services, and turned off things like FTP, Samba, and > so on, but it hasn't made much of a difference (according to top, > they weren't using much ram anyway). Gentoo optimizations can't account for a 10-15 performance factor in software startup times. A difference like that is probably a result of memory pressure, and the swap numbers above suggest that this is indeed your problem. If the machines at the lab have 256MB of memory and are using about 15MB of swap and your machine at home has 256MB of memory and is using 512MB of swap, then you're going to have to account for that 497MB. What's using it? After your machines has been running (slowly) for a while, do a "ps avx". The "DRS" column will give you rough idea of how many kilobytes of potentially swappable memory a process is using, and the "MAJFL" column will tell you how many times that process has experienced a major page fault (i.e., a request for memory that probably resulted in disk access including swapping). What are the worst offenders in that list? -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unexplained network problems
Marty Landman <[EMAIL PROTECTED]> writes: > > woody:~# more /var/log/kern.log | grep eth0 > Mar 4 09:11:41 woody kernel: eth0: Lite-On 82c168 PNIC rev 33 at > 0xe400, 00:A0:CC:40:3E:9B, IRQ 11. [ . . . ] Oh, I see you found the logs. Well, obviously the driver didn't write anything relevant to the logs. And I now see that the driver only writes information about transmission errors when its debug flag is set higher than the default. Now that your machine's been running for a while without trouble, does the "ifconfig" output show any accumulated transmission errors? If not, I think your best bet is to try swapping cards with your wife's machine to determine whether it's really a hardware or software problem. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unexplained network problems
Marty Landman <[EMAIL PROTECTED]> writes: > > so I could've just done > > %ifdown -a && ifup -a Yes, that would work. In fact, "ifdown eth0 && ifup eth0" would just restart the specific interface. The "-a" flag just means all interfaces flagged with "auto" in "/etc/network/interfaces". > A fast steady blink, normal color (green for that particular nic). The > steadiness is what made it look strange, Okay, so, for whatever reason, the switch didn't like what the NIC was doing and, probably, disabled the port. > Newbie here, where are the kernel logs? I'm not ashamed to admit being > an idiot, obviously ;x All the logs are in "/var/log". Kernel messages, and just about everything else, are written to the "syslog" series of files. Like almost all the files in "/var/log", these files are rotated periodically (for "syslog", it's on a daily basis), so you'll find the most recent messages in "syslog", the next most recent in "syslog.0", and older ones in "syslog.1.gz" through "syslog.6.gz". Because "syslog" is rotated daily, the relevant messages may have already fallen off the end if this happened more than a week ago. Fortunately, there's also a dedicated kernel logfile that contains only kernel messages, the "kern.log*" series. These are rotated once a week, so you should be able to find your messages in there, if you can't find them in "syslog*". > If it's either the nic or the driver I vote for the driver since that > nic's identical twin is installed on my wife's workstation which is > running w98. But your specific unit could be faulty. For that matter, the cable between your NIC and the switch might be flakey, or the specific port on the switch might have a problem. Since you're fortunate enough to have a twin NIC, I would suggest swapping the NICs, being careful to swap the cable and port connection at the same time (so your wife's machine is using the same NIC-cable-port combination that you ran into trouble with on your machine). If the problem resurfaces, you have very strong evidence for a driver problem. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: unexplained network problems
Marty Landman <[EMAIL PROTECTED]> writes: > > ifconfig eth0 down > rmmod tulip # using this driver for my netgear fs310tx nic > modprobe tulip > /etc/rc.d/networking restart > bash: /etc/rc.d/networking: No such file or directory > route add gw 192.168.0.1 > gw: host name lookup failure > ping 192.168.0.1 > ping: sendto: network is unreachable You meant "/etc/init.d/networking", not "/etc/rc.d/networking". (Also, your "route add" command had the wrong syntax as someone else pointed out, but you shouldn't need the "route add" command if your "/etc/init.d/networking" command works properly.) In other words, you reloaded the module, which might have had some effect, but you didn't bring the interface back up. That's why the ping failed here. > The light for this nic on my switch was on and blinking so I removed > it and reinserted; stopped blinking, went through the commands above > again with similar results and then rebooted. Depending on your switch, this may mean the switch didn't like the way the NIC was behaving and automatically disconnected it from the network (until you disconnected and reconnected the cable). Usually, of course, the LED blinks when there's activity. Was this a different kind of blink than the usual activity blink, say a different colour or a different blinking rate? You said there were 1311 TX errors in the "ifconfig" output. The Tulip driver sometimes writes information to the logs. Do you have any lines like: eth0: Transmit error, Tx status NNN. or any other network-related lines in the kernel logs during the malfunction? Without further information, it looks like your NIC (either because it's faulty or there's a problem with the Tulip driver) is behaving badly---jabbering or causing too many collisions---and the switch is disconnecting it from the network so it doesn't bring everything down. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate leap year
Paul Johnson <[EMAIL PROTECTED]> writes: > > Get a real NTP client? chrony didn't screw up... Surely "ntp-simple" is a "real" NTP client. I mean, it's *the* NTP software package (i.e., the official reference implementation of the NTPv4 protocol). The "-simple" part just means it doesn't include drivers to interface with radio and other reference clocks like "ntp-refclock" does. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: ntpdate leap year
Greg Madden <[EMAIL PROTECTED]> writes: > > I use ntp-simpl. This is a leap year, 29 days in February, but ntp is > short by one day. I can adjust the date manually but when ntp runs it > sets me back a day. Is there away to tell ntp about leap years ? First, not to be a wiseass, but you might want to check that the source you're using to manually set your computer's clock is correct. Just because your watch says it's March 2 doesn't make it true. NTP should already know everything it needs to about leap years. If you're synchronizing to a single NTP server, that server may be misconfigured (or may have handled the leap year incorrectly). To see if this is the case, install the "ntpdate" package if you haven't already. Try setting the correct date and time manually, then run: ntpdate -q time.windows.com ntp.gci.net your-ntp-server.wherever.net This will produce output like: server 207.46.130.100, stratum 2, offset 0.001581, delay 0.06384 server 208.138.129.21, stratum 3, offset -0.005527, delay 0.06911 server x.x.x.x, stratum 2, offset 0.004713, delay 0.04111 1 Mar 22:48:29 ntpdate[30017]: adjust time server 137.82.1.3 offset 0.004713 sec For each server line, the offset gives the difference, in seconds, between that server's clock and your machine's clock. If your offset from known, good servers like "time.windows.com" and "ntp.gci.net" is a couple of seconds or less but your offset from the server you're trying to synchronize to is enormous (around 86400 seconds, say), then that server is misconfigured. If the server offsets are all just a few seconds, but "date" still shows a bogus date, something's probably wrong with your timezone setting. Does "date -R" show an offset of "-0900" at the end, which should be the correct value for Alaska at this time of year? -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: wireless bridge, & nic IP addressing
"Rodney D. Myers" <[EMAIL PROTECTED]> writes: > > I just got my wireless internet this morning, and have run into a > small problem. > > The wireless bridge, attached to my nic has been assigned a static IP > (for the time being), and to get my nic (eth0) to find it, it was also > assigned an IP address in my ISP's range. Not a good thing. Assuming you haven't already solved your problem... This is one of those cases where people can easily talk right past each other. Most things marketted as "wireless bridges" aren't bridges at all. However, I gather from your email address that you're talking about a Skyriver connection, so they might very well give you a box with a 10BaseT connection that for all intents and purposes is a dumb bridge. But if this is the case, I have no idea what you mean when you say the wireless bridge "has been assigned a static IP (for the time being)". Who assigned it this IP address? You, through a configuration screen of some kind? Or were you just told that a static IP address had been assigned and assumed they were talking about the "bridge"? If the latter, then the other response you got was correct. Your bridge doesn't have an IP address at all (or at least not one that should concern you). Instead, you want to assign the static address that you thought was assigned to the bridge (namely, 4.2.2.1 from your other message) to "eth0" on your Linux firewall and have that firewall do NAT for the home network connected to "eth1". Therefore, ifconfig eth0 4.2.2.1 netmask 255.255.255.0 broadcast 4.2.2.255 up route add default gw 4.2.2.3 should give the desired result *IF* your netmask really is 255.255.255.0. But, of course, use the static IP address, netmask, broadcast, and gateway addresses you were actually assigned. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: How do I get a warm fuzzy feeling about kernel upgrade?
[EMAIL PROTECTED] writes: > > I have reaffirmed that I'm clueless this morning. I found this security > bulletin: > http://lists.debian.org/debian-security-announce/debian-security-announce-2003/msg00212.html > > this morning. This worried me since I just installed debian last week on > a server directly connected to the internet. I'm confused because it says > in the text that the update is "version 2.4.18-14 of the i386 kernel > images" but in the list of upgraded packages all of them seem to have just > a -12 The security bulletin was in error. The updated kernel *source* package version was -14; the i386 kernel image packages were -12. If you look at your: /usr/share/doc/kernel-image-2.4.18-1-k7/changelog.gz you'll see: . Added TASK_SIZE check to do_brk in mm/mmap.c at the top. That's the fix. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: print command
Vivek Kumar <[EMAIL PROTECTED]> writes: > > Is there any other command to print any character say "*" 80 times.. The Bash-specific solution already proposed: for (( i=0; i<80; ++i )); do echo -n '*'; done; echo has the advantage that, since "echo" is an internal command, the entire loop is executed in the current shell process. (But see below.) For some other possibilities that do require launching one or more processes, these work: head -c80 /dev/zero | tr '\000' '*'; echo or: dc -e '80[[*]n1-d0/dev/null these are the elapsed real times (in seconds on my slow computer) for various solutions proposed in this thread: X secs/1000 -- - python -c 'print "*"*80'35.488 for x in `seq 80`; do echo -n \*; done; echo10.772 yes '*' | head -n 80 | tr -d '\n'; echo 9.051 for ((i=0;i<80;i++)); do echo -n '*'; done ; echo9.773 perl -e 'print "*"x80 ."\n"' 6.727 head -c80 /dev/zero | tr '\000' '*'; echo5.787 dc -e '80[[*]n1-d0 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: procmail "solution" against swen
Kevin Buhr <[EMAIL PROTECTED]> writes: > > Um, credits go to Kevin Buhr on alt.sysadmin.recovery, thank you very > much, unless Victor and I happened to come up with exactly the same > recipe down to the byte range and choice of Base64 line. ;) Okay, I found Victor's post, and it looks like Victor and I *did* come up with the same choice of Base64 line (for an obvious reason---it contains the URL of the vanity counter the virus author is using to keep track of the spread and so is unlikely to give a false positive), but I can still comfortably take credit for the particular procmail formulation posted in this thread. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: procmail "solution" against swen
[EMAIL PROTECTED] writes: > > Credits to go Victor Duchovni. He posted it on the postfix-users list > after some experiments with body_checks. It does do a very good job > stopping these mails indeed. Um, credits go to Kevin Buhr on alt.sysadmin.recovery, thank you very much, unless Victor and I happened to come up with exactly the same recipe down to the byte range and choice of Base64 line. ;) -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why such volume with W32/Swen@MM?
Kevin Buhr <[EMAIL PROTECTED]> writes: > > At least one technical description of Swen (which I can no longer > find) states that [ . . . ] Found the reference. See: http://www.f-secure.com/v-descs/swen.shtml under the heading "Spreading in e-mails and to newsgroups", second paragraph. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Why such volume with W32/Swen@MM?
Bill Moseley <[EMAIL PROTECTED]> writes: > > I'm curious why I'm getting so many of these viruses sent to me. On > various technical lists I've read of lots of people that are getting > hammered by the mail, too. At least one technical description of Swen (which I can no longer find) states that, in addition to spreading by *posting* Usenet articles, Swen also collects addresses from recent Usenet posts. A "strings" search shows that Swen is set up to issue "HEAD" and "NEWNEWS" commands to news servers. It wouldn't need to do this to post, only to collect recently used addresses, so it seems likely this is correct information. Note that this list is echoed to the Usenet group "linux.debian.user" on many servers, so anyone posting here is probably getting lots of copies. I've gotten 3400 since I started keeping track Thursday at 1:00pm PDT (all dutifully discarded by "procmail"). That doesn't include the 350 or so copies that have been stripped of the executable attachment by antivirus software or the copies that appear to simply be missing the attachment without evidence of being actively cleaned by anything (a bug in Swen, perhaps?). -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Traffic Shaping -- I Need a Push in the Right Direction
Kevin Buhr <[EMAIL PROTECTED]> writes: > > Specifically, you can set up an HTB (which is included in standard > 2.4.x kernels but probably requires a patch for 2.2.x kernels) Oh, sorry. Looks like it's standard from 2.4.20 on but would require a patch for earlier 2.4.x kernels. You could use the CBQ discipline instead. The Adv-Routing authors can't say enough bad things about it, but at least it's standard. ;) -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Traffic Shaping -- I Need a Push in the Right Direction
"Greg Sims" <[EMAIL PROTECTED]> writes: > > I need to perform bandwidth traffic shaping on a Debian Gateway > machine. I've done a good bit of surfing but have not been able to > find what I want. The 2.2 and 2.4 kernels contain an immense amount of packet scheduling code. Start by reading section 9 of the "Adv-Routing-HOWTO" (which is probably installed under "/usr/share/doc/HOWTO/...") and then install the "iproute" package and take a look at: /usr/share/doc/iproute/README.iproute2+tc.gz and the "tc" manpage. Specifically, you can set up an HTB (which is included in standard 2.4.x kernels but probably requires a patch for 2.2.x kernels) queue discipline that filters packets based on their source or destination IP addresses and limits their rates separately. See section 9.4.5 of the Adv-Routing-HOWTO for an example (that limits based on ports rather than addresses). -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: **Getting** dhcp to write /etc/resolv.conf
Kenward Vaughan <[EMAIL PROTECTED]> writes:
>
> The only thing I can see which appears a bit odd is a line in the
> dhclient-script:
>
> make_resolv_conf() {
> if [ "x$new_domain_name" != x ] && [ x"$new_domain_name_servers" != x ]; then
>^ compared with ^^^
> echo search $new_domain_name >/etc/resolv.conf
No, there's nothing overtly wrong with that---the comparisons will do
the same thing.
Try adding two lines to the beginning of that function:
make_resolve_conf() {
echo new_domain_name="$new_domain_name" > /etc/resolv.log
echo new_domain_name_servers="$new_domain_name_servers" >>/etc/resolv.log
. . .
and bring the interface "ifdown" and back "ifup". Make sure that
"/etc/resolv.log" is created and that it shows that both variables
have been assigned non-null values. It may be that your ISP's DHCP
server is simply not configured to provide both pieces of requested
information, even when asked.
If the problem is that its supplying the servers but not the domain
name, replace the whole function with:
make_resolve_conf() {
if [ x"$new_domain_name_servers" != x ]; then
> /etc/resolv.conf
chmod 644 /etc/resolv.conf
for nameserver in $new_domain_name_servers; do
echo nameserver $nameserver >>/etc/resolv.conf
done
fi
}
[[ There's no particular reason to use an ISP-supplied search path
anyway. Do you really want to use "http://www/"; to access your ISP's
homepage? ;) ]]
> I _could_ keep running off the old isp's DNS, but that doesn't feel right,
> and I think it contributes to some latency (not critical to me, but my wife
> keeps looking for the perfect shopping experience... :)
Well, you should be able to determine your new ISP's DNS servers and
hardcode them manually. Try "host dns.yourisp.net", "host
dns1.yourisp.net", or "host dns2.yourisp.net" and try out those IP
addresses. Or, take a peek at your ISP's support pages. They
probably have it documented somewhere.
--
Kevin <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Routing
doc's on that? I've gotten MPPE working for the PPTP client, but I compile my kernels the old-fashioned way, not using the Debian-sanctioned "kernel-package" way. I assume it's relatively straightforward: once the "kernel-patch-mppe" package is installed, install the appropriate "kernel-source-*" package and the "kernel-package" package, and follow the latter's instructions to recompile a patched kernel and create Debian "kernel-image-*" and "kernel-headers-*" packages. Then, install those, and you've got an MPPE-patched kernel. To make any real use of this, though, you also need an MPPE-patched PPP daemon. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Routing
"Mark Maas" <[EMAIL PROTECTED]> writes: > > When I use the MS pptp client and login to the pptpd server on this machine > i can ping all networks from the client, but cannot reach the internet. > Pinging google.nl results in the name beeing resolved to the ip adress of > google.nl but the request don't ever reach google.nl... Oh boy... We're getting to the stage where you may have to explain what it is you're trying to accomplish and give a lot more detail about your network topology. Why are you setting up this PPTP tunnel? Are you using it as an (expensive) way to connect a single machine on the intranet to the Internet through the ADSL (??) on the Linux box? Or are you eventually aiming to have a Windows machine out on the big, bad Internet connect to your intranet through the secure PPTP tunnel and have access to all intranet machines and also the rest of the Internet? Besides the ADSL on your Linux box, are there any other connections from the intranet to the Internet? Are other machines forwarding traffic through your Linux box right now? Or are they even able to connect to the Internet? Do you have a single external IP address or a block of them? In a nutshell, what's probably going wrong is that your Windows machine, whatever its original IP address was, reconfigured itself when you started up its PPTP client. It's now using its original IP address only to shuttle packets across the PPTP tunnel to and from the Linux box. For all other purposes, it's using the IP address assigned by the copy of "pppd" running on the Linux box (in the "remote IP address" line in your log). This is presumably some address on the 192.168.8.x network, say 192.168.8.123. When you ping, say, the intranet gateway "192.168.8.4", from the Windows box, the packet goes out with source IP 192.168.8.123 and destination 192.168.8.4 across the PPTP tunnel. The Linux box forwards the packet out to the "eth0" interface where 192.168.8.4 picks it up and generates a reply. The reply needs to go to 192.168.8.123, and that's fine---the Linux box has configured itself to do proxy ARP for 192.168.8.123, so packets destined for that address go to your Linux box which recognizes that it's destined for the Windows machine and shuttles the packet back across the PPTP tunnel and you get your reply. Unfortunately, when you ping "google.nl", the packet goes out with source IP 192.168.8.123 across the PPTP tunnel. The Linux box forwards the packet out to the "eth1" interface (becaause its destination matches the default route), and it goes out to "google.nl" with an internal source IP. It either gets filtered at your or "google.nl"'s ISP perimeter (when the firewalls notice that its source IP is an unroutable address) or "google.nl" actually gets the packet, formulates a reply, and discovers it can't deliver it. If you really want things to work this way, you need to do source NAT on behalf of the Windows machine (or any other internal machine that's trying to send packets to the Internet through your Linux machine) so packets that hit the Internet can find there way back to your Linux machine through its public (ADSL) IP address. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Routing
"Mark Maas" <[EMAIL PROTECTED]> writes: > > This is what my table looked like: > > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse > Iface > localnet* 255.255.255.0 U 0 00 eth0 > 217.149.32.0* 255.255.240.0 U 0 00 eth1 > default 217.149.34.113 0.0.0.0 UG0 00 eth1 > default 192.168.8.4 0.0.0.0 UG0 00 eth0 Whoops... Sorry for that earlier blank reply. My finger slipped. I assume "localnet" here is 192.168.8.0 and that 192.168.8.4 is the gateway on the local LAN which you were successfully using to contact the other firms before bringing up "eth1". I'd suggest doing: route del default gw 192.168.8.4 to get rid of that spurious extra default route and: route add -net 192.168.3.0/24 gw 192.168.8.4 route add -net 10.1.0.0/24 gw 192.168.8.4 to try and route the two other private LANs through the old gateway. Your final routing table will look like: localnet* 255.255.255.0 U 0 00 eth0 192.168.3.0 192.168.8.4 255.255.255.0 UG0 00 eth0 10.1.0.0192.168.8.4 255.255.255.0 UG0 00 eth0 217.149.32.0* 255.255.240.0 U 0 00 eth1 default 217.149.34.113 0.0.0.0 UG0 00 eth1 To make this change permanent, assuming you're using "/etc/network/interfaces" and "eth0" is configured statically, you want to comment out its "gateway" line (which adds that incorrect default route) and add two "up" commands to statically route the two "special" networks through the old gateway, like so: auto eth0 iface eth0 inet static address 192.168.8.whatever network 192.168.8.0 netmask 255.255.255.0 broadcast 192.168.8.255 # gateway 192.168.8.4 up route add -net 192.168.3.0/24 gw 192.168.8.4 up route add -net 10.1.0.0/24 gw 192.168.8.4 Is "eth1" a DHCP-configured ADSL modem or something? If so, it'll get the default route to 217.149.34.113 assigned automatically during the DHCP negotiation, so there's nothing to add for that. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Routing
"Mark Maas" <[EMAIL PROTECTED]> writes: > > This is what my table looked like: > > Kernel IP routing table > Destination Gateway Genmask Flags Metric RefUse > Iface > localnet* 255.255.255.0 U 0 00 eth0 > 217.149.32.0* 255.255.240.0 U 0 00 eth1 > default 217.149.34.113 0.0.0.0 UG0 00 eth1 > default 192.168.8.4 0.0.0.0 UG0 00 eth0 > > so what do I need to do? > > Just keep: route add -net 192.168.3.0/24 eth0 ? > > Thanks again. > > - Original Message - > From: "Kevin Buhr" <[EMAIL PROTECTED]> > To: "Mark Maas" <[EMAIL PROTECTED]> > Cc: <[EMAIL PROTECTED]> > Sent: Friday, September 05, 2003 1:28 AM > Subject: Re: Routing > > > > Kevin Buhr <[EMAIL PROTECTED]> writes: > > > > > > route add -net 192.168.3.0 netmask 255.255.255.0 eth0 > > > > Oh, and David Z Maze is probably correct. Even if this works, it > > probably isn't what you want to do anyway. > > > > When you only brought "eth0" up and were able to reach the > > 192.168.3/24 and 10.1.0/24 networks, what did your routing table look > > like? If you had a 192.168.8.0/255.255.255.0 route to eth0 and a > > default route to a specific gateway machine (say 192.168.8.1), then > > packets to those other networks were going out via that gateway > > machine and you want to duplicate that environment in your new > > configuration. > > > > -- > > Kevin <[EMAIL PROTECTED]> > > > > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: route function of actiontec 1524, please help
"eric" <[EMAIL PROTECTED]> writes: > >I had actiontec 1524 dsl modem, firmware 1.60.50.0.51, with one pc > (wtih linux, redhat 9) with one static ip, I want to broadcast > webserver by above > but when I type in my (static ip) in my browser, it show the modem > configuration page, not my apache test page which I suppose to see. I don't have an Actiontec modem, but it looks like it's a combination DSL modem and NATting router. Working from their user manual, I gather that---under the "WAN IP Address" advanced setting page---you've set the modem up to either obtain its (static) IP address automatically or you've specified the static IP address manually. In particular, you don't have "transparent bridging" enabled, so your WAN IP address is your global static IP address and your RedHat machine is obtaining a 192.168.0.xxx IP address from the modem via DHCP, right? If this is correct, I'd suggest that you begin by entering the advanced configuration and double-check that "remote management" is disabled and that, on the "port forwarding" screen, you have an entry that will forward packets for TCP port 80 to the *internal* IP address, say 192.168.0.2, of your PC. Now, even with everything set up this way, it may *still* be the case that when you "http://my.static.ip/"; from within your internal network, you get the configuration pages for your modem (or you get nothing at all). In fact, this probably *is* what will happen; it's just a pecularity of how NAT works. The only way to get to your RedHat webserver from your internal network will be to do "http://192.168.0.2/";. The key is whether or not a buddy, connecting from the *outside* to "http://my.static.ip/"; gets your RedHat webserver or not. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Routing
Kevin Buhr <[EMAIL PROTECTED]> writes: > > route add -net 192.168.3.0 netmask 255.255.255.0 eth0 Oh, and David Z Maze is probably correct. Even if this works, it probably isn't what you want to do anyway. When you only brought "eth0" up and were able to reach the 192.168.3/24 and 10.1.0/24 networks, what did your routing table look like? If you had a 192.168.8.0/255.255.255.0 route to eth0 and a default route to a specific gateway machine (say 192.168.8.1), then packets to those other networks were going out via that gateway machine and you want to duplicate that environment in your new configuration. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: "route" issue
Nick Lindsell <[EMAIL PROTECTED]> writes: > > I have a problem with portsentry in that I cannot remove > blocked IPs. The portsentry.conf is configured to use > "route add -host $TARGET$ reject" for any $TARGET that crosses > its path - in my previous experience "route del -host $TARGET$ reject" > would remove the offender from the reject route. However on this > machine I get "SIOCDELRT: no such process" and the target remains > in the routing table. If you manually perform: route add -host 192.168.3.1 reject route del -host 192.168.3.1 reject does it still fail? Which Debian version of the net-tools package do you have installed? It works for me with net-tools 1.60-4 on the stable Debian 2.4.18-bf2.4 kernel. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Routing
"Mark Maas" <[EMAIL PROTECTED]> writes: > > Ok thanks, tried it but I get: > > SIOCADDRT: Invalid argument > > when I issue: > route add -net 192.168.3.0 eth0 Include the netmask anyway: route add -net 192.168.3.0 netmask 255.255.255.0 eth0 or, if you prefer the short version (CIDR style address): route add -net 192.168.3.0/24 eth0 The manpage was presumably correct at some point, but it's wrong now. This was either a kernel or "route" change. The IP address class system has been largely obsoleted by CIDR, and that's made it inappropriate for either "route" or the kernel to try to guess a netmask for the most part. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: [OT] Why does X need so much CPU power?
Neal Lippman <[EMAIL PROTECTED]> writes: > > Aside from the present market penetration of X (which could also be > used to argue to stick with Windows instead of ever having adopted > Linux), what would be the obstacle (other than, of course, the > time/effort for development) for a new graphics paradigm to sit atop > Linux? [Yes, I know there'd be a lot of apps to redo and so forth as > well, although if there were a Gtk+ compatibility layer...) I see three ways in which you've answered your own question. Obstacles include (i) existing "market" penetration of X, (ii) time and effort required to develop a replacement, and (iii) a large installed base of existing X-compatible applications. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Bizarre one-way network disconnection
Mark Roach <[EMAIL PROTECTED]> writes: > > All of a sudden, the server will reject all network communication on > eth0, won't respond to pings, no ssh, no samba. (ssh gives the message : > No route to host) However, if I ssh in through eth1 I am able to ping > addresses _from_ eth0. If I ifdown eth0 && ifup eth0 everything starts > working again. Sounds a little like it's not responding to ARPs on the "eth0" side. Machines that don't already know "eth0"'s MAC address can't send packets to it until it responds to an ARP request, but it's not a problem when pinging out, for example, because the target host (or the router) remembers the IP->MAC mapping when it receives the request packet and knows where to deliver the reply on that basis. Running "tcpdump" on both the misbehaving host and another host while trying to (unsuccessfully) ping in to the misbehaving host would certainly help show what's going on. > The only strange thing that I noticed is that each time this has > happened, when I do a "ps ax" the process listing pauses midway, and > hangs for a few seconds before displaying the next process (an smbd > process) there is nothing in the syslog, ifconfig doesn't show any > errors on the interface Is this on the console? Or over an SSH connection? -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: telnet localhost slow, telnet 127.0.0.1 ok
[EMAIL PROTECTED] writes: > > If I run telnet localhost 22 then I have to wait 15-30 seconds before it > connects; with telnet 127.0.0.1 22 it connects at once. I have the same > results using other open ports. Does telnet -4 localhost give the same delay? If not, then the problem is IPv6 support. Even though all your resolution configuration files are set up correctly, "telnet" is using "getaddrinfo()" to grab *both* IPv4 and IPv6 addresses for "localhost". The former gets looked up in the "hosts" file, but the latter goes out to your nameserver. If you want, you can add "localhost" to the "::1" line in "/etc/hosts" like so: ::1 ip6-localhost ip6-loopback localhost and that'll allow you to do "telnet localhost" without delay. That may cause problems with other programs, though, which might try to use IPv6 addresses in preference to IPv4 addresses without falling back if they can't connect to the IPv6 address. And, if the nameserver you're using always chokes on IPv6 queries (not just for "localhost"), then "telnet anyhostname" will always give the same delay, and you're better off aliasing "telnet" to "telnet -4". -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: is exim attempting to relay ???
"Michael D. Schleif" <[EMAIL PROTECTED]> writes: > > However, correct me if I'm wrong, it looks to me that -- initially -- > fetchmail gets an email message from one of my many remote mail servers, > and passes it off to exim for local processing. > > The To: header is mangled, and noted, and 550 is returned. > > Then, somehow -- this is the part that I do not understand, and that I > want to *STOP* happening -- [EMAIL PROTECTED] > attempts to send an email -- containing this 550 error -- to some > address unknown to me. Note: the URL is only one (1) of many > _different_ examples I am seeing. Keep in mind that there are SMTP envelope MAIL FROM and RCPT TO addresses that often get stripped even from the "full" headers of a message. If they do appear, they will appear as "Return-Path" and "Envelope-To" respectively. In this case, it appears that the original message was sent with envelope headers indicating a mail from <[EMAIL PROTECTED]> and to <[EMAIL PROTECTED]>, but the actual "From" and "To" headers were garbage. Nonetheless, the mail server at "helices.org" accepted it for delivery to the "mds" mailbox. When your "fetchmail" (on "bragi", I gather) ran to grab mail from your <[EMAIL PROTECTED]> mailbox, it ran across this message and attempted it to deliver it via SMTP to the local mail server on "bragi". But "bragi"'s server didn't like the empty "To" header and complained with a 550 error, so "fetchmail" tried to bounce the error message back to the envelope "from" address, namely <[EMAIL PROTECTED]>. It tried to send this bounce by connecting to your localhost's SMTP port (on "bragi") and sending a bounce with an envelope indicating a mail from <[EMAIL PROTECTED]> and to <[EMAIL PROTECTED]>. Unfortunately, the "exim" on "bragi" wasn't configured to rewrite the envelope "from" address of the FETCHMAIL-DAEMON to something more useful. It passed it on to "trout" which passed it on to the qmail server on "mail.private.network", and qmail attempted to deliver it via SMTP to the mail server on "smtp.wanadoo.fr". That host bitched about the invalid envelope "from" address (because "bragi.private.network" is clearly invalid outside your private network) during the SMTP exchange with "mail.private.network", so "mail.private.network" tried to bounce it back to <[EMAIL PROTECTED]>. To do this, it contacted the SMTP server on "bragi.private.network", but "bragi" didn't have an account or matching alias for "FETCHMAIL-DAEMON", so it refused the message. The "qmail" program on "mail.private.network" was so fed up at having its bounce bounce that it mailed the postmaster in frustration. Got that? You can easily head this off at the pass by passing "fetchmail" the "--nobounce" command line option. With this option, it'll just send bounces to the postmaster on "bragi" instead of trying to deliver them back to the message sender. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Passing parameters to a telnet session?
Marc Shapiro <[EMAIL PROTECTED]> writes: > > Does anyone know if there is a way to pass a parameter to a telnet session? A mechanism exists for the "telnet" client to send arbitrary environment variables to the "telnetd" server. The Debian version of the client will send USER (if "-a" or "-l" is specified on the command line), PRINTER, and DISPLAY by default. It also sends TERM, though via a technically different mechanism. It can also be told, via an "environment export ..." command at the "telnet>" command prompt or in an /etc/telnetrc or .telnetrc file, to send other environment variables. The Debian version of the server, however, for security reasons, will only accept values set for USER, LOGNAME, DISPLAY, POSIXLY_CORRECT, and TERM. You can't overload USER, because that's the value the "-l" is sending, and you can't generally overload TERM because it undergoes some processing that changes its value to "unknown" if it isn't recognized. So, the easiest one to use (the one that the client sends by default and that the server accepts without question) is DISPLAY, so if you do: DISPLAY=format_harddisk telnet hostname -l username DISPLAY=destroy_universe telnet hostname -l username you're all set. The only caveat is that the value shouldn't start with ":" or "unix:" since that will result in the local hostname being stuck in there. > I have set up a user on one box that does not require a password to > log in. This is generally considered dangerous if the user's shell is an unrestricted shell such as Bash, even if you create a special-purpose ".bash_profile" to try and restrict the user's activities. For example, while Bash is reading ".bash_profile", if it receives a keyboard interrupt (i.e., a SIGINT signal), it will stop processing and drop the user to a shell prompt. Oops! -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Spamassassin and procmail
Antony Gelberg <[EMAIL PROTECTED]> writes: > > I currently use fetchmail and procmail to get and sort my mail. I'd > like to use spamassassin as well, however when I add > > :0fw: spamassassin.lock > | /usr/bin/spamassassin > > to my .procmailrc, it works ok, but then the mail gets delivered to > /var/mail/, rather than following the rest of my procmail > recipes. Rich's answer is right. You need the "-P" option for the stable version of SpamAssassin, and you don't need a lock, so the complete rule should read: :0fw | /usr/bin/spamassassin -P As an extra bit of advice, you might want to consider upgrading to the version in "unstable" instead (which, by the way, doesn't need the "-P" option). A while back, I decided to give SpamAssassin a try to see if it did a better job than the homespun rules that I'd accumulated over the last few years. I installed the 2.20-1woody version from stable, and I was very disappointed. It missed almost everything. For me, it was essentially useless. Before tossing SpamAssassin entirely in the bit bucket, I decided to give it a second chance by installing 2.55-3 from unstable. It was like night and day. The newer version does a much, much better job. The 2.55-3 source package builds fine on a vanilla Woody machine. (In fact, the unstable "spamassassin" binary package would install fine on a vanilla Woody system, too, except it has an apparently unnecessary dependency on "spamc" which depends on the unstable C library.) -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Identify dhcp client to server using hostname
Robert Ian Smit <[EMAIL PROTECTED]> writes:
>
> I have created a range of dynamic ip-numbers and have tried to find
> a way to identify those hosts that need a fixed address using host
> statements.
The client-supplied "host-name" parameter won't do it. Instead, you
need to configure the client to send a textual "dhcp-client-identifier",
and the server will use that (instead of its MAC address) to identify
it.
That is, on the DHCP client side, you want:
send dhcp-client-identifier "myhost";
and on the DHCP server side, you want:
host myhost {
option dhcp-client-identifier "myhost";
fixed-address 192.168.1.7;
}
I haven't tested it myself, but that should work. Search for
"dhcp-client-identifier" in the dhcpd.conf(5) manpage for more
information. The following shows another example someone got to
work:
http://mail.gnu.org/archive/html/bug-grub/2000-12/msg00045.html
He also included a "send host-name" tag in the client configuration,
though I don't think that's necessary.
--
Kevin <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pptp client behind firewall
Kevin Buhr <[EMAIL PROTECTED]> writes: > > Greg MATTHEWS <[EMAIL PROTECTED]> writes: > > > > I have a linux server setup with pptpd which appears to be working ok (port > > 1723 is definitely open) but i'm having trouble connecting to it from behind > > my firewall - a debian pentium running stable using iptables. > > You have my sympathies. Someone pointed out to me in email that there's a userspace "pptpproxy" daemon (not Debianized yet) that you can run on the firewall to tunnel PPTP connections. I've never tried it myself, but it would undoubtedly be much simpler to set up if it does what you want. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pptp client behind firewall
Greg MATTHEWS <[EMAIL PROTECTED]> writes: > > I have a linux server setup with pptpd which appears to be working ok (port > 1723 is definitely open) but i'm having trouble connecting to it from behind > my firewall - a debian pentium running stable using iptables. You have my sympathies. > does this mean that i need to forward ip type 47 to a specific host on my > private net? this would mean only one machine could ever use pptp so this > doenst sound right. You need to patch your firewall kernel with the PPTP connection tracking patch. Unfortunately, this patch is evidently broken in the latest stable release of Patch-o-matic (20030107 from "www.netfilter.ord")---at least, I never got it to work on forwarding the responses from the server properly---so you need to pull the latest from CVS. The patch you need to apply is "extra/pptp-conntrack-nat.patch", and you'll need to enable (compiled in or as modules): Networking options: Connection tracking GRE protocol support (CONFIG_IP_NF_CT_PROTO_GRE) Y/M PPTP protocol support (CONFIG_IP_NF_PPTP) Y/M in your kernel configuration. If you go the module route, you'll need to ensure that both "ip_nat_pptp" and "ip_nat_proto_gre" modules are manually loaded. (Neither will be autoloaded, and PPTP NAT won't work if they aren't both loaded.) Finally, then, the usual kinds of forwarding/masquerading rules: iptables -A FORWARD -i $EXTIF -o $INTIF -m state \ --state RELATED,ESTABLISHED -j ACCEPT iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT iptables -t -A POSTROUTING -o $EXTIF -j MASQUERADE (or whatever you probably already have in place) will take care of the rest automatically. Ugh. I can vouch for this working under 2.4.20 (tested with only one Windows client behind the firewall connecting to a Windows server elsewhere, though), and I can probably put together a patch against vanilla 2.4.20 for you, if you don't want to bother dealing with Patch-o-matic. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dhclient problem
David Fokkema <[EMAIL PROTECTED]> writes:
>
> This is the log with the right options (yesterday I forgot some, so I
> didn't send it since I didn't think it would be useful). I hope you still
> have some time to look at it, the problem keeps annoying me. Thanks!
Well, after every DHCP REQUEST, there's an immediate ARP packet from
81.91.5.1 trying to resolve the offered IP address.
It looks like 81.91.5.1 is trying to deliver the DHCP ACK packet by
using ARP to resolve the IP address that hasn't yet been assigned to
your machine instead of by grabbing the MAC address from the chaddr
field of the packet. Your ISP can see the ACK leave their DHCP server
at 81.91.1.11; the problem is that their broken router/relay at
81.91.5.1 isn't delivering the ACK to your machine. It's just
unsuccessfully ARPing for the offered IP address and dropping the
packet. That's so broken it hurts.
The fact that it delivers the OFFER correctly and that changing your
MAC address, client identifier, or both can convince it to correctly
deliver the ACK packet (by broadcast) just makes it weirder.
You may be able to work around the problem by setting the BOOTP
broadcast flag on your DHCP REQUEST---this may convince the errant
relay to broadcast the DHCP ACK instead. Here's a patch against
Debian's dhcp-2.0pl5 to do so:
--- dhcp-2.0pl5/client/dhclient.c.orig Sun Mar 30 15:16:18 2003
+++ dhcp-2.0pl5/client/dhclient.c Sun Mar 30 15:20:03 2003
@@ -1586,9 +1586,11 @@
} else {
memset (&ip -> client -> packet.ciaddr, 0,
sizeof ip -> client -> packet.ciaddr);
+#if 0
if (can_receive_unicast_unconfigured (ip))
ip -> client -> packet.flags = 0;
else
+#endif
ip -> client -> packet.flags = htons (BOOTP_BROADCAST);
}
I'll be surprised if that works, but it's worth a try.
--
Kevin <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Permission denied -- Say what?
[EMAIL PROTECTED] writes: > > bash:/home/ronin/files/seti$ ./setiathome > bash: ./setiathome: Permission denied Is the partition containing your home directory mounted "noexec", perhaps? -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dhclient problem
David Fokkema <[EMAIL PROTECTED]> writes: > > Since this post, I contacted my ISP and they say they can see my REQUEST, > and hey! Yes, there goes the ACK! Another REQUEST, another ACK! But > somehow, I don't receive them. I use tcpdump | dhcpdump and that > works perfectly, I can see all DHCP options, addresses and things and the > REQUEST is for the same address as the original one. Even the OFFER offers > this old address. The DHCPACK leaves the server (they say), but doesn't > reach me. If you aren't seeing the alleged DHCPACK packet even in raw "tcpdump" output, there's not much you can do. If you have a "smart" router or something between your ADSL modem and your computer, it may be doing something remarkably stupid to those ACKs, but if your computer is directly connected to the ADSL modem and no ACK packet gets to your machine, then the problem is obviously theirs. Try running: tcpdump -s 2000 -nXe (without piping it through "dhcpdump", in case that's swallowing some of the packets for some reason) and go through a connection attempt. Send that output along, and I'll take a look at it. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: dhclient problem
David Fokkema <[EMAIL PROTECTED]> writes: > > I don't know what's going on since the syslog shows that after > each DHCPREQUEST there is a DHCPOFFER from the correct server. That's broken server behaviour. The server is supposed to respond with either a DHCPACK or a DHCPNAK (or not respond at all). If it responds with DHCPACK, the client gets the address it asked for. If it responds with DHCPNAK, *then* the client generates a DHCPDISCOVER to which the server responds with a DHCPOFFER. Anyway, after getting no correct answer to a DHCPREQUEST for a bit, the DHCP client is supposed to fall back to a DHCPDISCOVER to get a new address. By default it does so in only 10 seconds, but this can be overridden by the "reboot" value in "/etc/dhclient.conf". Perhaps you've overridden it with too large a value? Or what does "dhclient hangs (almost) forever" mean? If you can't get it to work correctly, a quick fix is to add a line near the beginning of the "/sbin/dhclient" to: rm /var/lib/dhcp/dhclient.leases Then, since the DHCP client has no leases, it'll start out by doing a DHCPDISCOVER without delay. Depending on the DHCP server at the other end, you may still get the same IP address every time. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: What the heck did emacs do with my email?
Joseph Barillari <[EMAIL PROTECTED]> writes: > > If you can, you may want to suspend mail delivery when you do that, in > case sendmail decides to write to the mailspool at the same time you > do. (Incidentally, does anyone know a better way to lock a mailspool > before appending messages to it?) The "mail-lock" and "mail-unlock" commands from the "lockfile-progs" package will lock and unlock a mailbox in a way that should be compatible with all Debian mail programs. Mail locks are considered stale after about five minutes, so you need to finish your fiddling within that time window or use "mail-touchlock" to keep the lock fresh. (See the mail-lock(1) manpage for more information.) -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tar ate my symlinks
Brian Victor <[EMAIL PROTECTED]> writes: > > I believe you're right. It was "exiting now" when untarring /proc, > which apparently prevented it from finishing the job. > > >tar -jtvf linuxbackup.tar.bz2 | egrep '^l' | \ > > perl -lane 'print "ln -snf $F[7] $F[5]" if (@F == 8 && $F[6] eq "->")' \ > > > FIX_MY_SYMLINKS > > This gave me warm unix fuzzies like you wouldn't believe. I'm glad it worked, but since you went this route, be extra careful that there were no more files after that "exiting now" error that you missed restoring! > One last question. I'm planning on doing a similar procedure to my > other machine. Is there anything other than /proc that I need to > exclude? I was surprised to find that /dev made it through intact. It'll depend on your kernel and what other "special filesystems" you've mounted. If you run "mount" without options, it'll list what's mounted, and you can figure out what isn't a real filesystem from there. In addition to "proc", you might see "usbdevfs", "devpts", and "shm" filesystems that shouldn't be copied. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: tar ate my symlinks
Brian Victor <[EMAIL PROTECTED]> writes: > > >Can you tell if the tarball actually has the symlinks in it but the > >restore messed up, or if the files are stored incorrectly and restored > >correctly? > > I don't know; is there any way to tell that in a compressed (or even a > decompressed) tarball? Sure, use: tar tvfj linuxbackup.tar.bz2 | less and you'll get an "ls -l"-style directory listing. The symlinks should have an "lrwxrwxrwx" mode, and you should be able to see their values. I believe you've been bitten by a queer bit of "tar" behaviour. Some time ago, there was a security bug where "tar" could be tricked into following a symlink it had just created and then overwrite files outside the directory where the restore was supposedly contained. To fix this problem, "tar" was patched to use a regular file placeholder for possibly troublesome symlinks. When "tar" completes, it's supposed to go back and change those placeholder files back into symlinks, but if "tar" crashes (or is stopped) before the restore completes, the symlinks will be left as (zero-length) regular files. Perhaps you interrupted the restore, or perhaps it crashed while trying to restore "/proc" or something. Then, "tar" wouldn't have had a chance to go back and fix all the placeholders. I would suggest reattempting the restore without extracting "/proc". "tar"'s exclude mechanism is singularly stupid, so: tar -jxv --exclude=proc will exclude *all* files and directories named "proc", not just the top-level one. However, you can do: ssh '...' | tar -jt | egrep -v '^proc' >FILES_TO_RESTORE ssh '...' | tar -jxv --files-from=FILES_TO_RESTORE to avoid restoring the problematic "/proc" directory while still restoring any "proc" files and directories hiding elsewhere. If you still end up with screwed up symlinks no matter what you do, all is not lost. On the 192.168.2.10 machine, run the following command: tar -jtvf linuxbackup.tar.bz2 | egrep '^l' | \ perl -lane 'print "ln -snf $F[7] $F[5]" if (@F == 8 && $F[6] eq "->")' \ > FIX_MY_SYMLINKS That'll create a shell script capable of recreating all the broken symlinks (except those where the symlink filename or value contained whitespace---hopefully you don't have any of those that matter). After you've double-checked that the commands in FIX_MY_SYMLINKS aren't total nonsense, then on the broken machine, run: cd / ssh 192.168.2.10 cat FIX_MY_SYMLINKS | sh and your symlinks should be restored. Hope that helps. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Iptables is driving me nuts (beginner)
"n/a" <[EMAIL PROTECTED]> writes: > > Apparently there's something i'm not getting thru my thick skull about > packet filtering. I think others have pointed out the main problem---packets being forwarded by the machine don't pass through the INPUT and OUTPUT chains. This behaviour differs from the old "ipchains" behaviour: see iptables(8), the section titled "COMPATIBILITY WITH IPCHAINS". If you're trying to build your tables based on old "ipchains" examples, you'll run into trouble. > Could someone explain to me in text (no diagrams) how a > packet is evaluated and then processed tru the chains, also what is done and > not-done any more after a packet has passed thru a chain. There's a good explanation in the Netfilter Hacking HOWTO: http://www.netfilter.org/documentation/HOWTO//netfilter-hacking-HOWTO.html though it uses a couple of ASCII diagrams. In a nutshell, the kernel networking code includes several netfilter "hooks" where packets can be examined, dropped, modified, rerouted, or whatever. An IP packet arriving on any interface (even the loopback interface) is first passed to the NF_IP_PRE_ROUTING hook. This happens even before the kernel decides whether the packet is destined for a local process or needs to be forwarded to another machine. Next, the packet enters the kernel routing code which decides what to do with it. Packets directed at a local IP address pass through the NF_IP_LOCAL_IN hook. After this, they are dealt with by the kernel in the "usual" manner (including passing the data up to an appropriate user process). Packets that must be forwarded don't pass through this hook. Instead, they pass through the NF_IP_FORWARD hook, then through the NF_IP_POST_ROUTING hook, and then to the appropriate device driver. Locally generated packets are handled first by the routing code before being passed to the NF_IP_LOCAL_OUT hook (which can change their routing) and then the NF_IP_POST_ROUTING hook, and then to the appropriate device. The upshot is this: Packets arriving from a different machine and directed at one of the firewall's IP addresses pass through the NF_IP_PRE_ROUTING and NF_IP_LOCAL_IN hooks. Packets arriving from a different machine that must be forwarded to another machine pass through the NF_IP_PRE_ROUTING, the NF_IP_FORWARD, and the NF_IP_POST_ROUTING hooks. Locally generated packets destined for another machine pass through the NF_IP_LOCAL_OUT and NF_IP_POST_ROUTING hooks. Packets sent from the firewall back into the firewall (e.g., "telnet localhost") pass out through the NF_IP_LOCAL_OUT and NF_IP_POST_ROUTING hooks and then back in through the NF_IP_PRE_ROUTING and NF_IP_LOCAL_IN hooks. That's all assuming that none of the hooks interfere with the packet. Since the hooks can drop, modify, or otherwise reroute the packet, the actual path of a packet can be even more complicated. The hooks can do all sorts of things. One of the main things they do is apply the rules that you set with "iptables". If the only table you configure is the "filter" table, its three chains INPUT, OUTPUT, and FORWARD, will be applied at the LOCAL_IN, LOCAL_OUT, and FORWARD hooks. Therefore, packets will only pass through one of the three filter chains (except packets through the loopback which are processed by the OUTPUT chain on the way out and the INPUT chain on the way in). In your case, it looks like you need to do some masquerading for your internal LAN, so things get a bit more complicated. If you configure the "nat" table, too, destination NAT (i.e., changing the destination of a packet) in the "nat" PREROUTING chain is applied in the PRE_ROUTING hook: a packet arriving from the big, bad Internet that *seems* to be for the firewall's external IP address could be *really* for the firewall or it might be for a machine on the internal LAN. The destination NAT is applied at the PRE_ROUTING stage so that it can rewrite the destination address before the kernel routing code makes its decision. Then, it gets passed to LOCAL_IN or FORWARD as appropriate. (Destination NAT can also be applied via the "nat" OUTPUT chain in the OUTPUT hook if you want to redirect locally generated packets for some reason; and source NAT is applied via the "nat" POSTROUTING chain in the POST_ROUTING hook after the packet has already passed through the "filter" OUTPUT or FORWARD chains.) I hope that helps. I can't tell from the configuration rules you gave exactly what it is you're trying to do. It looks like you want internal hosts to be able to make direct SMTP and POP connections to a certain subnet of external hosts and web connections to "kottweb", but you want to prevent all other connections (except web connections proxied through the firewall). Can you clarify this? -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: adduser wants root passwd though I am root
[EMAIL PROTECTED] writes: > > I am root and want create new user ... > > $> whoami > $> root > $> adduser test > $> Password: Under the hood, "adduser" uses "useradd" (from the "passwd" package) to do its work. My "adduser" and "passwd" packages are the current Woody/stable version: adduser version 3.47 and passwd version 2902-12. When I run "adduser" as root, it does *not* prompt for the root password; it immediately creates the new user and prompts for the new user's password (twice). If I run "adduser" as a regular user, it prints the message: adduser: Only root may add a user or group to the system. It's possible this behaviour is changed in newer versions of "adduser" and "passwd", but your suspicions are justified. The MD5s for "adduser" and "useradd" on my (Woody) system are: b7783a6c5057bd917b303f8c79ab4186 /usr/sbin/adduser c62fb94c47a8af25768e5db96e5a6d52 /usr/sbin/useradd -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Shadow RAM can't be disabled
"Mark A. F." <[EMAIL PROTECTED]> writes: > > Here are the forced Shadow RAM settings: > > F000 - (System BIOS) > E800 - EFFF (Rapid Resume BIOS) > E000 - E7FF (System POST) > > Upper Memory Boundary F200 > > I am working through my installation of Debian. > > What misbehaviors might I experience due to these settings? Most likely, none. Unless the descriptions are inaccurate, those ranges are plain old ROM, so shadowing won't cause a problem. The only worry is shadowing over top of a range of memory that some device (like an ISA network card, for example) is using for memory-mapped I/O, but those are the ranges you've already disabled. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: AW: pppd problem...
"Christof Hurschler" <[EMAIL PROTECTED]> writes: > > Sorry, but how do I get rid of the "tap0" default route? The "diald" dial-on-demand package is probably doing it. You can "apt-get remove diald" to get it out of the way, at least until you get things working with "pon/poff". -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: pptp ...
Karoly Vegh <[EMAIL PROTECTED]> writes: > > Im trying to get into my firm's LAN with pptp from a cable-provider at > homel. Colin Ellis is right. > Feb 26 10:41:59 hb pppd[1271]: rcvd [CHAP Failure id=0x0 "E=691 R=1 > C=3BEDB47127E2081CF23A3BBDAA861AF9 V=3"] The error code here E=691 is a simple authentication failure. > ps. ofcourse i changed the real IP to SERRVER_IP, useraccount to 'username' > and so on through the whola mail. I hope you also changed your real password to "password", or else you're trying to log in with password "password". Besides that, the culprit is probably extra backslashes. Instead of: name "domainname.atusername" you want: name "domain\\username" with the backslash doubled instead of quadrupled. Note that "domain" should probably be the simple NT domain name (not a fully qualified hostname). Similarly, the entries in "chap-secrets" should look like: # Secrets for authentication using CHAP # clientserver secret IP addresses domainname\\username PPTP YourRealPassword SERVER_IP PPTP domainname\\username YourRealPassword SERVER_IP with the backslashes doubled, not quadrupled. On my PPTP tunnel, if I use double backslashes, it works. If I quadruple the backslashes like you've done, I get the same authentication failure you do. -- Kevin Buhr <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple NICs with Monolithic kernel
Michael West <[EMAIL PROTECTED]> writes: > > The final thing which I still do not understand is that, after I > passed the ether= kernel parameters for each card, only eth0 would > work. But if I `ifdown eth0` then only eth1 would work. Finally > if I `ifdown eth1` then eth2 would work. This one has got me > stumped. I'm pretty sure that has nothing to do with the "ether=" kernel parameter. It would work the same either way. It's just the way Linux does business: if you run "tcpdump -i eth1" on the Linux machine, you'll probably see it accepting packets on eth1. However, there's nothing forcing it to *reply* to, say, a ping on the same interface the original packet came in on. With "eth1" connected, packets are coming in on that interface but trying to go out on the disconnected "eth0". You have to bring "eth0" down before they go out on "eth1" instead. Then, you have to bring "eth1" down before they go out on "eth2" instead. There are ways to force interface affinity, in the sense that a packet whose source address is 10.0.1.11 can be forced to route out on eth1, but that requires something like rule-based routing. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Multiple NICs with Monolithic kernel
Michael West <[EMAIL PROTECTED]> writes: > > I tried passing kernel parameters > > ether=11,0x2000,eth0 ether=10,0x4000,eth1 ether=9,0x6000,eth2 Actually, if I read the source right, these aren't having any effect. They certainly aren't doing what you want them to do: they aren't determining which physical card gets assigned to which logical device. > Now I can only ping all three addresses if eth0 is connected by cable. > eth1 and eth2 no longer respond though ifconfig output has not changed. Maybe check again---I believe the machine will behave the same whether you include that kernel setup string or not. If it's a genuine effect, see if there's any difference in the kernel log messages between the two cases. The behaviour can---in theory---vary from driver to driver, but here's the way it should work for the eepro100 driver and most other PCI drivers. Whether the eepro100 driver is loaded as a module or compiled into the kernel, at some point its initialization function will be called. The initialization function uses the standard kernel "pci_module_init()" function which, ultimately, enumerates the PCI devices in bus/device/function order, the same order you see the devices if you do a "cat /proc/pci". At this point, the behaviour can differ from driver to driver, but the eepro100 driver allocates the next "eth%d" device, binds it to that card, and overwrites the irq and I/O port base with the correct values for the card, completely ignoring the values you supplied in the setup string. The order *is* deterministic, you just can't determine it using the kernel setup string---eth0 through eth2 will always be assigned in bus/device/function order, which means they'll be assigned in order according to the physical PCI slot. I believe the person who said most drivers probe in MAC-address order was mistaken. According to an old mailing list post by Donald Becker: http://beowulf.es.embnet.org/listarchives/linux-tulip/1999/04/0048.html the 3c509 driver is unique in activating multiple cards in MAC address order. The PCI drivers all (?) detect them in PCI bus/device/function order. This gets much more complicated if you have PCI cards of multiple types (they are enumerated in bus/device/function order *within* each driver, but the order the driver initialization functions are called depends on the order they're compiled into the kernel, more or less). If you have (E)ISA legacy cards or certain motherboard chipsets, it's complicated even further. > Also if I bring the interfaces down and backup I get an error both > ways on the last interface. The order of the interfaces does not > matter. [ . . . ] > ifup eth1 > ifup eth0 > ifup eth2 > SIOCADDRT: File exists You can see which command is generating this by running "ifup" with the "-v" option. "ifup" implicitly does a: route add default gw 10.0.1.3 eth0 (or eth1 or eth2) for each "ifup" with a "gateway 10.0.1.3" line, and I assume that's the culprit. I don't know why it's working twice but failing the third time. Again, the "-v" flag might help. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: set up a LAN DNS so that it doesn't conflict with external DNSes
Jerome "Lacoste (Frisurf)" <[EMAIL PROTECTED]> writes:
>
> My needs are the following:
> - from my LAN I want that the address xxx.mydomain.com resolves directly
> to our server (192.168.1.2).
> - I want all my former settings to work. I.e. www.mydomain.com resolves
> to the ISP located site.
>
> I managed to do the first step. Unfortunately, my bind configuration
> made is so that I couldn't resolve www.mydomain.com anymore. Everything
> else (google, slashdot) resolves correctly.
You presumably made your local server authoritative for
"mydomain.com", and put an SOA record for "mydomain.com" and an A
record for "xxx.mydomain.com" in your zone file, but you didn't
include any records for "www.mydomain.com".
You have a few choices:
1. You can keep doing things that way and manually duplicate the
address record your ISP has for "www.mydomain.com" in your own zone
file. If your ISP changes the IP address out from under you, you'll
need to manually fix your own records.
2. You can keep doing things that way and delegate the
"www.mydomain.com" domain to your ISP's name server using an NS record
on your local name server. This is terrible DNS practice (because the
ISP's name server won't normally have an SOA record for
"www.mydomain.com"; instead, it'll have one for "mydomain.com" that
conflicts with the one *you* have), but that doesn't particularly
matter for an internal DNS server, and I believe things will work
correctly in this particular case. No guarantee, though...
3. You can make your local server authoritative for
"xxx.mydomain.com" instead of "mydomain.com" and include SOA and A
records for *that* domain name. This will work fine unless you later
decide that there are lots of names at "mydomain.com" that you'd
rather have resolve to local hosts and "www.mydomain.com" is the only
exception. Then, you either need a separate zone file for every such
host, or you need to switch to method 1 or 2.
> I tried to play with BIND's configuration through webmin, but I didn't
> make it work as expected. Worse I broke my first working step.
I've never used "webmin" so I don't know what it botched up. To
implement scheme (3) above, what you want is this. In what follows,
I'm assuming that xxx.mydomain.com (192.168.1.2) is also the machine
running your local DNS service.
/etc/bind/named.conf:
[ . . . ]
// add entries for other zones below here
zone "xxx.mydomain.com" {
type master;
file "/etc/bind/db.xxx.mydomain.com";
}
/etc/bind/db.xxx.mydomain.com:
; authoritative for $ORIGIN xxx.mydomain.com
@ in soa @ hostmaster (
20030217 ; Serial
28800; refresh period (8 hours)
7200 ; retry interval (2 hours)
604800 ; expire time (7 days)
86400 ) ; negative TTL (1 day)
in ns @
in a 192.168.1.2
--
Kevin <[EMAIL PROTECTED]>
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: how to get rid of the staircase effect
martin f krafft <[EMAIL PROTECTED]> writes: > > apsfilter. is there another method, maybe one with less weight? Well, the "ifhp" package contains the "standard" LPRng input filter, assuming you're using LPRng. If you want a dumb filter (one that doesn't make any effort to, say, print PostScript to non-PostScript printers or do the right thing with DVI files sent directly to the printer), "lpf" is included in the "lprng" package, and the LPRng-HOWTO (included in the "lprng-doc" package) mentions using it: 4.10.3. The Jaggies - LF to CR-LF Conversion With lpf Let me add that, in the past, I've had nothing but trouble using HP's JetDirect... erm... directly. They've probably improved things since I last had to deal with it, but their old network stack couldn't handle more than one connection at once so, if a job was printing, the printer would just refuse new connections until it completed; sometimes jobs would simply mysteriously get lost; the printer would just get wedged as machines trying to print jobs fought for its attention; and on and on. The solution was (and is) to designate one machine as the spooler for that printer and have all the other machines send the jobs through it. This is straightforward to set up using LPRng, and it has the added bonus that you can install and configure all sorts of fancy printer filtering stuff on just the one, spooling, machine and have all the clients take instant advantage of it. (Samba can be used to provide shared printer service for any Windows clients that are lounging around, too.) This is well worth setting up, in my opinion. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Special case of VPN : how can I do this ?
"eric" <[EMAIL PROTECTED]> writes: > > in my peer/dsl-provider > pty ... > it also have similar situation, > but I really did not know why my pppoe keep not work > that is in 2.4.20 kernel of 686 from unstable Which version of "pppd" are you running? Since about 2.4.2, the 2.4.x kernels have required "pppd" version 2.4.0 or later. "pppd" version 2.3.x won't work. If your "pppd" is up to date and still doesn't work, check your "/var/log/syslog" after a connection attempt. Are there any messages in there? -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Special case of VPN : how can I do this ?
Lucas Nussbaum <[EMAIL PROTECTED]> writes: > > I'd like to setup a VPN between my own computer and a computer in my > university, on which, of course, I don't have root access. You could look at the "slirp" package. The "slirp" server runs with normal user privileges on the remote machine and mimics a PPP server for the benefit of a "pppd" daemon running on the local machine. The usual way of setting it up would be to give your "pppd" an appropriate "pty" configuration line to automagically SSH to the remote machine and launch "slirp" through the resulting connection. My guess for the right "pty" line is: pty "ssh -t -e none remotehost slirp ppp" Because "slirp" only runs as a normal user process, there are limits to what it can do, of course, but for web browsing it will probably work quite nicely. Be careful of your routing, too. Add an explicit route for the remote Solaris machine through your "real" network interface before changing your default route to the new tunnel interface (or letting PPP do it). Otherwise, the first packet you send will be tunnelled back through the tunnel in an infinite loop. Oops. Googling for "ssh slirp tunnel" might help. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: getting an address from DHCP without an interface
martin f krafft <[EMAIL PROTECTED]> writes: > > eth0:1 is a virtual interface of eth0, but it has the same MAC > address, so it will get the same IP assigned as eth0 did by the DHCP > server. Depending on the DHCP server at the other end, you may be able to use the ISC DHCP client (with an appropriately modified "/etc/dhclient-script"), and simply put: send dhcp-client-identifier 00:ff:de:ad:be:ef; in the "/etc/dhclient.conf" file, where 00:ff:de:ad:be:ef is whatever MAC address you want the DHCP server to use in assigning you your lease. A DHCP server is *supposed* to use this parameter to identify the client and only fall back to the MAC address (as supplied in the DHCP packet's "chaddr" field) if no client identifier is provided by the client. -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Procmail + debian +Qmail
Mikael Jirari <[EMAIL PROTECTED]> writes: > > I built the receipe > > :0 > * > $HOME/.Maildir/ > > and it works. Yes, this is the correct way to put all messages into a single maildir-format directory. Recompiling "procmail" is only necessary if you want to stop an empty "/var/spool/mail/mikael" file from being created everytime "procmail" runs (or if you want to change "/var/spool/mail/mikael/" into a maildir-style directory). -- Kevin <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
