Re: ls sort order
On Thu, Sep 14, 2006 at 01:01:25PM -0400, Eric d'Alibut wrote: I just noticed on a brand new install of testing that ls has begun to sort alphabetically, but mixes uppercase and lowercase together i.e. 'Pearl' comes before 'pearl' but after 'otter'. [...] A stable Debian version I maintain behaves the good old-fashioned way: [...] Is this some utf-8 mutation? Yup. If you want the old behavior, use this: export LC_COLLATE=C -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpMtxiCGKKOi.pgp Description: PGP signature
Re: Michelle Konzack's sex (was: Email programs that work.)
On Wed, Sep 06, 2006 at 02:27:09AM +0200, Michelle Konzack wrote: his first. Actually I think he did a fine job. ^^^ ^^ Do you know something I don't? I always thought that Michelle was female. Right. ;-) Er... Sorry Michelle. I do know Michelle from mutt-users, where I could swear I'd seen a post (from her) which referred to her as male. I remember specifically thinking that it was odd for a man to have the name Michelle. Obviously I was mistaken... FWIW, I work with a guy named Erin, and another named Kim (not an Asian family name, but a European first name). :-P In any event, I thought Michelle's post was fine. :-D -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpIHzkWzKpOB.pgp Description: PGP signature
Re: Email programs that work.
On Thu, Aug 31, 2006 at 02:28:24AM +0300, Micha Feigin wrote: Right now, on my system, t-bird is using 76MB RES 200MB VIRT memory. :( And I thought that sylpheed-claws-gtk2 is using too much at 17MB resources and 38MB virtual. Reminds me why I stopped using T-bird and a bunch of others. PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 18782 foo 15 0 3360 3356 1704 S 0.0 2.6 0:04 0 mutt This is one huge advantage of Mutt. The memory footprint is unbelievably small, particularly in light of how much power it offers. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgp0MnWvydDZQ.pgp Description: PGP signature
Re: Email programs that work.
On Thu, Aug 31, 2006 at 05:15:25PM -0700, Steve Lamb wrote: Michelle Konzack wrote: You read more then One message at a time? Yes. Person A says Person B said something important while talking to Person C. So you have Message A open so you can find what is referenced in Message B. Hell, I do it all the time just on debian-user. Surely you with your mail load have run into that situation once or twice. Personally, no... But then I only get about 2,000 messages a day. Not to say I never wanted to refer to a message (usually when the person replying has done a very poor job of quoting)... But I guess I am a bit better than you at keeping two ideas in my head simultaneously... I just go and look at the second message, read what I needed to read, and then go back to the first message. I don't see that this is a big deal. Very rarely, I might want to look at a second message simultaneously in order to copy-paste small details from one message into a message I'm composing, but the message I'm copying from is not the message I'm replying to. Despite what you say, this is no problem whatsoever. I just start a new screen in screen, run a second copy of Mutt, and look at the message. I could also just open another xterm and do the same thing, but usually it's not worth the extra screen real estate and time to ssh into my server. You are making a mountain out of a mole hill. Or rather, an ant hill. Best of all, when I do this, because the vast majority of memory pages are shared between the two copies of Mutt, my memory usage increases by ZERO (less than half a megabyte): $ free -m total used free sharedbuffers cached Mem: 123120 2 0 25 59 -/+ buffers/cache: 35 87 Swap: 196 15180 [start a new screen, start a second copy of mutt, view a different message...] $ free -m total used free sharedbuffers cached Mem: 123120 2 0 25 59 -/+ buffers/cache: 36 86 Swap: 196 15180 How does TB or any other GUI do here? I imagine all those data structures for managing child windows and the graphics that are in them must add up... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpE4lg41CuSq.pgp Description: PGP signature
Re: Email programs that work.
On Thu, Aug 31, 2006 at 01:16:02AM +0300, Micha Feigin wrote: Also, how do you set the encoding of the message, as otherwise it gets mangled along the way. Normally this is handled automatically by your terminal ($LANG) settings. If your environment is not configured properly you may have a problem, but if it is configured properly it generally just works with Mutt. I do this all the time with Korean (and Japanese, though that usually just amounts to typing people's names and a few greetings, as I can't really speak any Japanese). -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpAoUtq2JqiD.pgp Description: PGP signature
Re: Email programs that work.
On Wed, Aug 30, 2006 at 05:51:27PM -0700, Steve Lamb wrote: Michelle Konzack wrote: I send E-mails via smtp... = set sendmail=sendmail -oi No, that is via command line. If sendmail were not there how would you get mail out? But it IS there... so what's the problem? A simple minimal ESMTP engine might be more convenient -- and numerous solutions for that are available for mutt -- but being able to choose to use a full-fledged MTA like sendmail offers the user (or system administrator) a great deal of power. And if you are configuring mail on a mail server for a large number of users, it also saves them from having to make ANY configuration settings in their mail client for SMTP. So I would say zero is better than one. ;-) You claim that the lack of an SMTP engine is a weakness of Mutt. Even though I think Mutt would be better with that, I don't think it's a weakness. In some ways, it's a benefit: numerous SMTP engines already exist, so not including one makes Mutt easier to debug and maintain, which make its overall code quality better. This is the Unix Philosophy. It also provides the flexibility of allowing the user or system administrator to choose the SMTP engine they prefer, rather than forcing you to use theirs, which you may not like at all. Or, more importantly, which is easier to set up, sendmail (exim, postfix, qmail) or a single configuration option which consists of smtp.host.com. I happen to agree that Mutt should have a minimal SMTP engine, to make this easier for inexperienced and/or braindead users. But oh, wait... there's a patch (kind of like add-ons for Tbird) that does exactly that. So I guess this functionality really isn't lacking in Mutt, after all (using your own logic)... I don't know of an MTA which runs perfectly off a single configuration option and I've run or currently run Exim, Sendmail, Postfix and nullmailer. Even still, here again you're just making a mountain out of an ant hill. When you install Debian, it installs a MTA for you, and the installer asks you a couple of very basic configuration questions which are sufficient to meet the needs of the vast majority of basic users. Perhaps it's not one single configuration option, but the few questions it asks are not any more difficult, and there are only a handfull of them, so the practical difference is minute. It lacks filtering. This is a job for procmail and maildrop Procmail, the line noise of mail filters, no thanks. And neither of these are able to retrieve mail. Oh, right, that pesky MTA again. Fetchmail does a fine job of retrieving the mail. As far as procmail being line noise, that's just poppycock. If you want to feed it dumb regular expressions like [EMAIL PROTECTED] that will mostly work, certainly enough for someone like yourself who apparently only wants simple-minded filtering. But by using regular expressions, it offers the user so much more power to filter on very complex rules and criteria. You can't be bothered to take an hour to learn how to write regular expressions? Your loss... Regular expressions abound in the Unix world. They are so incredibly useful that if you take the time to use them, you will not believe how much easier they can make your life. Tools like grep, sed, perl, etc. become like instruments with which you can play masterful music. The others are sucking more... Mutt CAN handel IMAP boxes with more then 2 million Messages and there is not a singel GUI client which can handel this I've yet to fathom a need for a 2 million message mailbox. Not to mention the support structure behind it since 2 million would break or strain both maildir and mbox. Well, the numbers are silly, but the point is Mutt will not break until long after any of your favorite GUI programs will. Please try to remember that Michelle is not a native English speaker, and is trying to make his points as best he can in a language which is not his first. Actually I think he did a fine job. Mutt's memory footprint is so small that it can handle gargantuan mail folders, half the size of which would cause most GUI mailers to crash due to memory exhaustion. It lacks a decent multi-account implementation. Having to configure every single item by hand without the concept of account inheritance is a nightmare. Here again you display your unwillingness to learn how to use your tools. Mutt's various hooks offer immense power; they can give you the same functionality as personalities, though you need to think about it a little differently. You may need to organize your mail very carefully into folders, to make your folder hooks easy to configure. You can have essentially an infinite number of personalities using them, and in addition to that you can change individual configuration options, set custom headers, and do a whole lot more, based on the folder you're in, the people you're sending to, or various other criteria. It's a LITTLE
Re: Email programs that work.
On Fri, Sep 01, 2006 at 07:44:00AM +0100, Wulfy wrote: PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 18782 foo 15 0 3360 3356 1704 S 0.0 2.6 0:04 0 mutt This is one huge advantage of Mutt. The memory footprint is unbelievably small, particularly in light of how much power it offers. But that is not a fair comparison with T-bird... what about all the other programs you must use to get the same functionality? Oh, very well... PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME CPU COMMAND 18782 foo 15 0 3360 3356 1704 S 0.0 2.6 0:04 0 mutt 9019 smmsp 15 0 560 12424 S 0.0 0.0 0:00 0 sendmail 19462 foo 25 0 668 668 584 S 0.1 0.5 0:00 0 procmail 19270 foo 15 0 2608 2608 1736 S 0.0 2.0 0:00 0 vim I had to force a procmail to run long enough to catch by running a fairly large mailbox through it using formail. I suspect to do a single message (the normal usage case) the footprint would be smaller. But no matter. Even at that, we're talking about a WHOPPING 7MB of TOTAL memory usage, including my editor, the sendmail submission daemon, mutt, and procmail. RSS of a little more than 4MB. Oh, yes... I do run sendmail on the machine, so there are listener daemons that are using some memory too. But they don't count, because this machine actually IS my mail server, and you don't have those in Tbird. Mutt is compiled with pop and IMAP support, even though I don't actually use them (the theory being I might need them someday, and don't want to have to recompile in that event). And yes, mutt can retrieve mail. But it's better if you use fetchmail, if you want to do filtering, which can pipe the messages through procmail. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpoyhUc1fRmQ.pgp Description: PGP signature
Re: Email programs that work.
On Tue, Aug 29, 2006 at 04:13:05PM +0500, Dmitri Minaev wrote: Actually, considering the number of tools Mutt uses for work, I suspect that it 'sucks less' just because it does less. You retrieve mail with fetchmail or isync, filter it with procmail, write new messages with vim and send them with msmtp. What does Mutt do, then? ;) Quite a lot actually. Yes, it does hand off a lot of tasks to other programs which are specifically written to do those jobs. With good reason. vim, for example, is an extremely powerful editor with a relatively small memory footprint. It is superb at what it does. Why should mutt try to re-invent the wheel, or using your philosophy, the world? If the mutt developers tried to write a built-in editor to edit mail, it would be far less powerful than vim, would make mutt's code an order of magnitude more complex, and most importantly would be a monumental waste of time. If they did the job well, what they would end up with is... vim (or emacs). Only, embedded in the mailer. The same goes for procmail, with regard to filters. Instead, Mutt follows the Unix Philosophy: do one well-defined job, and do it well. And it does that. So, what does mutt do? It provides an excellent terminal-based user interface to read, sort, and (visually) organize and filter mail. It does an excellent job of searching through mail in individual folders using regular expressions. It does a pretty good job of managing multiple profiles using its various hooks... It's very smart about honoring various recipient headers, so you (usually) don't have to think about how to reply to mail to send it to the right people... Just press the right key for what you want to do. It allows me to change configuration settings on a per-folder basis. It allows me to use different colors to highlight mail from specific people, or mail about certain topics, or identify some criteria based on information in virtually any header in the message. It has good support for mailing lists, and excellent support for PGP messages (much better than pine, unless recent updates support the many new (i.e. not 20 years old) standards regarding e-mail encryption). A lot of GUI mailers don't get any of this right, or simply can't do it at all. And there's a lot of stuff it does that I don't have time to mention... Do I think mutt needs mail filters? Nope. I use fetchmail and procmail, and would continue to do so even if filters were available in my client, because those tools are the best BAR NONE at what they do. My coworkers are always complaining about their Outlook/Evolution filters losing mail to their spam filters... I just laugh. Does Mutt have weaknesses? Of course. But most of the ones people have highlighted in this thread either represent a misunderstanding of how mutt does things, and why it does them that way (i.e. they don't understand the Unix Philosophy and why that's a Good Thing); or they're just plain wrong. Mutt has vast power as a MUA, but along with that power comes the price of having to learn how to use it. A lot of people who complain that mutt can't do X simply haven't learned how. I generally like TUI tools, but neither Mutt, nor Pine give me what I get with GUI clients. You're right on this one, though actually Brendan Cully has done a tremendous job of improving the IMAP code over the last year or so. I haven't used IMAP in a very long time myself, so I can't speak to what improvements have been made; but I know that his changes have made a lot of people very happy. And I agree about having a basic SMTP engine too; MTAs can be a pain to set up even for seasoned administrators... A user should not have to go through all that just to forward outgoing mail to his ISP; and even if there are some small ones out there that aren't too hard to set up, many users don't have the option, because they don't control their mail system. That's an argument that comes up often... Anyway, TUI clients share the same problem -- you cannot open more than one message. Am I asking too much? :) Er... sure they can. 1. Start screen, or two xterms, or whatever. 2. run one copy of mutt, view your 1st message. 3. run another copy of mutt... ;-) Want more than that from a terminal-based MUA? Then yeah, you are definitely asking too much. Besides... you can only read one mail at a time, so what's the big deal? :) [No, this is not a serious question.] [1] - Won't even mention things like storing non-mail items in IMAP folders :) Hmph. They're called mail folders for a reason. They're for... storing mail. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpy9FSdPXtdd.pgp Description: PGP signature
Re: Email programs that work.
On Mon, Aug 28, 2006 at 08:55:44PM -0700, Steve Lamb wrote: Marc Wilson wrote: Uhhh, no. Either you delete all but the last n messages, or you delete messages older than n days. That's not according to a set of rules. That's remarkably inflexible. That is according to a set of rules. A limited set of rules but those *are* rules. Any reasonably intelligent person could surmise that what he meant was according to a reasonably flexible set of rules that the user could define. It does not do that. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgptkGSwrKMXO.pgp Description: PGP signature
Re: Email programs that work.
On Tue, Aug 29, 2006 at 10:49:32PM -0700, Steve Lamb wrote: Derek Martin wrote: Any reasonably intelligent person could surmise that what he meant was according to a reasonably flexible set of rules that the user could define. It does not do that. Sure it does. It is a reasonably flexible set of rules. It just isn't a highly flexible set of rules. Furthermore the user can define what those rules do. No... the rules are static, and there are exactly two of them. The user can only change the limits of the rules, not the rules themselves. This is not flexible by any sane definition of flexible. You're being an ass. Intentionally, I might add. Sorry, but where does a reasonable set begin short of, say, Python? Take a look at what Mutt can do, if you must know. It does not have Python, or any other scripting language embedded in it. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpPno1x1bZQf.pgp Description: PGP signature
Re: Error 21
On Sun, Aug 27, 2006 at 11:27:08AM -0700, Kelly Clowers wrote: On 8/27/06, Ottavio Caruso [EMAIL PROTECTED] wrote: What has KDE got to do with a fileserver? A server shouldn't have any windowing system at all... As someone who was once a total noob with linux, I assure you a file server does need a windowing system. I assure you it does not. I've run many file servers which had none for years. I wouldn't use X on a file server now, but if I hadn't used X on servers in the beginning, I would have given up long before I got to the point where I didn't need X. So... it's the noob that needs the GUI, not the file server. That is a correctable problem. :) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpfMeX6Q9R6o.pgp Description: PGP signature
Re: Error 21
On Mon, Aug 28, 2006 at 10:48:59AM -0700, Marc Wilson wrote: On Sun, Aug 27, 2006 at 11:27:08AM -0700, Kelly Clowers wrote: As someone who was once a total noob with linux, I assure you a file server does need a windowing system. To serve what possible need? How does serving files require X? How does having X *enhance* the ease of serving files? I think what Kelly means is that to an inexperienced system administrator, there are a lot of GUI tools that make overall adminstration of the server much easier to manage. Even after 11 years of managing Linux and Unix systems, I must admit that some tasks genuinely are easier to manage with their associated GUI front-end tools... even if I hate using them, and avoid them like the plague. The problem with such tools is they rarely encompass every configuration possibility, and they usually want you to do things their way. They tend to be a bit inflexible. But, for someone who is very inexperienced and just has basic needs, it's probably sufficient and a lot easier than trying to track down what file needs to be edited, or what man page needs to be read, if you can even figure out what piece of software does the job you're trying to reconfigure... But to say a file server needs X is just silly. What is needed is user (sysadmin) education. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgp34QWKJuw37.pgp Description: PGP signature
Re: how to make colour prompts for pdksh
On Wed, Jul 26, 2006 at 04:55:02PM +0200, Florian Kulzer wrote: Now that your pointing this out for me :) indeed I was using a '^' char followed by a '['. But how can I enter that control character? What is the keycombo for it? Check my previous email. I don't know how to do it in vi (unfortunately), but it can be done in emacs. With vi, when you are in edit mode (-- INSERT -- etc.), you can press CTRL + Q followed by ESC. (Release the other two keys again before you press ESC.) If you use colors you will see that '^[' is shown in a different color to indicate that it is a special character and not just '^' + '['. It is furthermore treated as one character when you move the cursor across it. If I may be pedantic... First of all you mean vim. The original vi does not support syntax coloring, and there are other vi clones which may behave differently than you describe (like elvis, etc.). Secondly, the key to use is dependent on your operating system and terminal settings. On Windows, the key seems to be CTRL-Q. On virtually any Unix platform, the default is CTRL-V but is configurable by the user, using stty or similar terminal control programs. The setting is controlled by your terminal, not by vim per se. You can see what it is currently set to using stty -a: $ stty -a speed 38400 baud; rows 24; columns 80; line = 0; intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = undef; eol2 = undef; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0; -parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts -ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc -ixany -imaxbel opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0 isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke Notice on the 4th line of output at the beginning, the entry lnext = ^V This is the key which is correct on your terminal. The lnext keyword is short for literal next character and is what you would use to change the key using stty. For example: stty lnext ^U ...changes the character to CTRL-U, though this isn't recommended as ^U normally corresponds to the kill character (not the same as the kill command) by default. These are the normal defaults for xterm and its cousins, which are based on the DEC vt100 family of terminals, as is the Linux console. Note from the output above that ^Q is assigned to start which is the XON character for terminal flow control, so it will not work as advertised above on this terminal. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpyZ80a8TE0I.pgp Description: PGP signature
Re: how to make colour prompts for pdksh
On Wed, Jul 26, 2006 at 09:47:39PM +0200, LeVA wrote: So either set konsole up to launch ksh as a login shell, or set ENV somewhere. You can test this with: $ ENV=~/.profile konsole Or launch konsole, and do: $ ksh -l The .profile is always gets parsed (both in a login and a non-login shell). This is not correct, unless you have a line such as the following in your .profile: export ENV=~/.profile However, your non-login shells will inherit exported variables from your login shell, so your prompts will still be set, etc. This is the difference between variables that are exported and not exported. When I start pdksh in a non-login shell, the .profile gets parsed, and the PATH and every other env.var. gets set. Only the aliases gets ignored, but why? Because you are mistaken... the .profile does not get parsed. The environment variables are being inherited from the parent shell. if the .profile was being parsed, your aliases would be there too. If I add the ENV=~/.kshrc line to my .profile and my ~/.kshrc contains my aliases, then I still can not see my aliases... You need to export ENV. This can be done as I did above, or like this: ENV=~/.profile; export ENV The man says that if the ENV parameter is set when the shell starts :) This is funny because I can set the ENV parameter in a shell, and I can not set it before running the shell :) Yes you can... you can export it from a parent shell. Something must be running already (eg. KDE) to be able to set up the variable. I can put a file which contains 'ENV=~/.kshrc' to my ~/.kde/env/ and that gets sourced by kde startup, so the ENV parameter will be set when I start konsole. Wait a minute... that is what I'm gonna do! :) And if you tried that, it didn't work either... because you didn't export ENV. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpUsjMTvqgTr.pgp Description: PGP signature
Re: X default fonts
On Wed, Jun 28, 2006 at 11:50:00AM -0600, Cameron Matheson wrote: This is a really un-optimal solution, but if you edit your /etc/fonts/fonts.conf, you can change the order that fonts are preferred (just search for the prefer tags). Move the fonts that are more readable nearer to the top. Unfortunately, fonts.conf is a file that shouldn't be changed... it would be better to edit local.conf, but I don't know enough about how fontconfig works to do that. I'll give this a shot... thanks. I'm still kind of wondering why such a crappy font gets chosen as the default though. Thin (cursive) script fonts being chosen as the default should never happen... FWIW, this is an automated install where all packages are configured non-interactively. Given that I will need to change this on a whole bunch of machines, I'd really prefer a solution that fixes it in the install process, rather than having to manually edit files on a large number of machines... If there's a better place to ask this kind of question, please let me know. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpKaakaQcJvg.pgp Description: PGP signature
X default fonts
Hi Folks, What I did: I'm using the debian installer to do an automated install of a bunch of workstations. We have various users who speak non-English languages, so I installed every font package I could. Problem: I myself speak Korean (albeit badly). After installing all the fonts, two undesirable effects have occured: 1. When I bring up Gnome's font configuration dialog, the fonts that are displayed in it are some kind of cursive script font. 2. Whenever I view Korean characters, the Korean font which is chosen to display the fonts is also some kind of hand-written script. These hand-written fonts are really hard to read, except at fairly large sizes. When I read English texts, the fonts that are displayed are not what I would prefer, but they're perfectly suitable. In the font configurator, I've left the fonts configured as the defaults, Sans, Serif, and Monospace. So the questions are, why does Debian choose these horrible fonts as the defaults, and how do I change it? I'll be more than happy to provide other information about my install, if it will help. Thanks! -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpvlaSNnlkoq.pgp Description: PGP signature
Re: Server REALLY slow after console messages
On Wed, Jun 28, 2006 at 09:37:07AM +1200, Simon wrote: On 6/28/06, Jo Shields [EMAIL PROTECTED] wrote: You've run out of RAM. Hmm... Could this be some sort of memory leak or something? Would anyone be able to offer any path of checking or solving this issue? Run top, hit 'F' to select a field to sort on, then n for %MEM. This will show you what processes are sucking up your RAM. Also run free -m to see how much memory you have, how much virtual memory you have, and how much of it is in use. Make sure you have as much as you think you have. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpdcI557vZZr.pgp Description: PGP signature
Re: Server REALLY slow after console messages
On Wed, Jun 28, 2006 at 09:52:42AM +1200, Simon wrote: OK, i had to restart the server as there was critical services running on it... After rebooting and running the commands above: Unfortunately it's too late... To see what is causing the problem, you need to look at it while the problem is happening... There might be something interesting in syslog, but I'm sorry to say, there probably won't be. If you want to post them on a website, maybe people can take a look... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpKBXhrxSONI.pgp Description: PGP signature
Re: Server REALLY slow after console messages
On Tue, Jun 27, 2006 at 05:24:02PM -0400, Carl Fink wrote: You're out of memory, just like the messages say. Presumably some process on that server has used it all, including all your swap. Eventually the process should be killed automatically or the program might segfault. If you can get on as root and stay on long enough to type some commands, you could do: dd if=/dev/zero of=/var/spool/swapfile bs=1024 count=262144 swapon /var/spool/swapfile Realistically, this isn't likely to help... He's already used up 5GB of virtual memory -- 2GB of RAM and 3 GB of swap space. At such a point, the problem is the system is thrashing the swap disk... that is, it is trying to rapidly pull processes back from swap space as the kernel changes context between all the runable processes. People still advocate having swap that's anywhere from 1.5 to 3 times your physical RAM... That made sense on ancient hardware with 8MB of RAM, when memory was relatively a lot slower and way more expensive, but I think on modern hardware, that idea is totally brain-dead. Part of the problem is that memory speeds have not kept up with CPU improvements (so context switches kill you), but mostly I think it's that memory is way, way faster than disk (especially as compared to 20 years ago), so virtual memory doesn't buy you as much as it used to on paleolithic hardware. If you're actively using 3GB of swap, there's no way your disks can keep up to the CPU's context switches, and your system is dead in the water (note: emphasis on ACTIVELY -- If you have a 3GB process swapped to disk, but it's just sitting around doing nothing, it's not going to kill your system... at least not until someone decides they need to use it again). The only real solution is to buy more RAM, particularly if this problem continues to reoccur. Though, someone suggested a memory leak... there's a real possibility that one of the processes (or more than one) does actually have one. That would be where getting output from top while the system is thrashing would be useful. It's difficult to get due to the state of the system, but totally necessary to figure out what's really going on. Steps that might help: 1. log in on the machine's console. There's less work for the system to do, compared with logging in over the network, so logging in locally should be easier. 2. Boost the priority of your shell (you must be root). This command will do it (including the $$): # renice -20 $$ If the system is at all capable of being responsive, this should make your shell usable. The $$ is an automatic shell variable which expands to the process id of your shell. Here's an example. First, let's show what the process id of my shell is: [EMAIL PROTECTED] ddm]# echo $$ 13357 Now, notice the NI value for that PID in the output of ps -elf, below: [EMAIL PROTECTED] ddm]# ps -elf |egrep $$|PPID F S UIDPID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 4 S root 13357 13355 0 76 0 - 1389 wait 22:44 pts/500:00:00 -bash 4 R root 13439 13357 0 76 0 - 1415 - 22:47 pts/500:00:00 ps -elf It's 0, which is the normal nice value for any process. This means the process has the default priority, same as every other normal process on the system. But by reducing the nice value, we increase the priority. Not exactly intuitive, I know... but just remember that by reducing the NICE value, we are making our process less nice than before. :) [EMAIL PROTECTED] ddm]# renice -20 $$ 13357: old priority 0, new priority -20 Now, notice the new NICE value in the output of ps: [EMAIL PROTECTED] ddm]# ps -elf |egrep $$|PPID F S UIDPID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 4 S root 13357 13355 0 60 -20 - 1389 wait 22:44 pts/500:00:00 -bash 4 R root 13460 13357 0 60 -20 - 1415 - 22:51 pts/500:00:00 ps -elf 0 R root 13461 13357 0 60 -20 - 1235 - 22:51 pts/500:00:00 egrep 13357|PPID We've changed the nice value to -20, as low as it can go, i.e. it's the least nice we can make our process. You must be root to reduce the nice value... Regular users can only increase it. The idea is to make processes which the user is running for a long time in the background be nice to other users... So, once you log in, make sure renice -20 $$ is the first thing you do. After that, the system may respond better for you... but also realize that all the other processes will run worse for everyone else. If your system is thrashing like this, about the only solution is to stop and restart proceses (or just reboot)... but the above is meant to give you a way to see WHY the system is falling over, so hopefully you can do something to prevent it after you do finally reboot the system. ;-) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpLinLp1WtdZ.pgp Description: PGP signature
Re: Server REALLY slow after console messages
On Tue, Jun 27, 2006 at 11:29:27PM -0400, Carl Fink wrote: dd if=/dev/zero of=/var/spool/swapfile bs=1024 count=262144 swapon /var/spool/swapfile Realistically, this isn't likely to help... He's already used up 5GB of virtual memory -- 2GB of RAM and 3 GB of swap space. At such a point, the problem is the system is thrashing the swap disk... that is, it is trying to rapidly pull processes back from swap space as the kernel changes context between all the runable processes. I wasn't suggesting it as a long-term solution, just an attempt to buy a few minutes of responsiveness in which to kill the exploding process. Yeah, I know... but the thing is, it almost certainly won't work. Your dd command is only going to make the disk busier, increasing contention, though even that doesn't really matter. If the system is thrashing with 3GB of swap used up, adding a couple of hundred megabytes isn't likely to change anything (I'm going to back this up, down below a bit). The system might not even be using most of the swap -- you could have 2GB of the 3GB free. The system is thrashing NOT because it's out of virtual memory (necessarily, though it might be), but because there is a significant amount of demand for certain processes to run which don't all fit in PHYSICAL memory at the same time. It will repetitively bounce the memory pages for those processes in and out of RAM/swap. Reading those pages from and writing them to the disk is what's killing performance -- compared to memory, disk is SSSLLLOOOWWW. Once this process of thrashing starts, it usually just spirals until the system dies a painful death, unless the admins can catch it before it gets out of hand and kill the offending process(es). Please allow me to illustrate: Let's say you had a system with 1GB of RAM and 4GB of swap, and two processes that were actively running on it. Let's say process A had a resident set size (roughly the amount of memory which must be in physical RAM for the process to be runable) of 600MB. Process B has a RSS of 500MB. You only miss having enough physical RAM by 100MB... but even still, before one of these processes can run, the other one must be (at least partially) swapped out to disk. For the sake of simplicity, let's pretend nothing is using memory other than these two processes. Remember that processes don't actually run simultaneously (on a single-CPU system at least, but SMP is another discussion), they take turns. If process A is running, and it becomes process B's turn to run, the system will need 500MB of free ram to run B. But it only has 400MB free, so it will need to swap 100MB out to disk to make room for process B. If your disk can transfer 40MB/s, that swap will take 2.5 seconds. So you have to wait 2.5 seconds before process B is able to run. Then, after process B runs for 100 milliseconds (or whatever time slice the kernel allocates to it -- something similarly small, usually), it becomes process A's turn to run again. It has to swap 100MB of process B out, so that it can swap the original 100MB of process A back in. That's 200 MB! Now your swap will take about 5 seconds. And the part that sucks is, you have 4GB of swap space allocated, but you're only actually using about 100MB of it!!! Oh, that, and your system is taking about 5.01 seconds to do 0.01s worth of useful work. Now, on a busy system, multiply that by 50 busy processes, all competing for time... Granted, I chose abnormally large (but far from impossible) resident set sizes to illustrate the point, and simplified the problem a lot, but essentially, that's what's going on. And that's why adding 256 MB of additional swap when the system is already thrashing probably won't help at all. It's also why having a huge amount of swap space is mostly just a total waste of disk space (not entirely -- there's swapping unused processes to trade for buffer cache). You're much better off just buying about twice as much RAM as you think you'll need (or just buy as much as your budget can possibly allow for), and configuring a small amount of swap (maybe 300-500MB) just for emergencies, or so the kernel can swap unused processes in order to fill RAM with buffer cache (to make disk I/O faster, by caching frequently used blocks in RAM). That way you can use all those extra gigabytes of what used to be swap space for storing your pr0n and MP3's. ;-) In addition, having only a small amount of swap probably will help your system cope with thrashing much better! Since there's a lot less virtual memory, processes will be killed by the kernel sooner, which means it will be a lot harder for the system to get itself inexorably wedged by a backlog of processes which all need to be swapped into RAM before they can run. Instead of being swapped, they'll just die. :-D Now, that's still bad for your users, but at least the system will perform better for the ones who manage to get service... ;-) The
Re: multiple identities with mutt
On Mon, Jun 26, 2006 at 06:03:42AM -0500, Ron Johnson wrote: Why? I have TBird. Besides, the answer isn't always write one. Some of us aren't whiz-bang software engineers, thanks. With Python and the curses, Gtk, Qt, POP3, IMAP, SMTP RCF822 modules, writing a new MUA shouldn't be *that* imposing of a task. If you know nothing about programming, I assure you that it is a monumentally imposing task. Linux isn't just for programmers... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpwSAkjpEV9K.pgp Description: PGP signature
Re: What does it mean 'LANG=C'
On Sun, Jun 25, 2006 at 11:15:52AM -0500, Ron Johnson wrote: Derek Martin wrote: On Sun, Jun 25, 2006 at 10:48:28AM -0500, Ron Johnson wrote: When US keyboards have the Euro symbol on it, then it will have happened. Well, I don't think that is or should be a requirement... I mean, why limit that idea to just the Euro symbol? Said nothing about limit and only. The point was that when US h/w is internationalized enough to have foreign symbols on it, typing them will be, by default, mundane. The point I was trying to make is that this is an extremely arbitrary measure of whether or not a particular keyboard, or the OS you're using it under, is Unicode-friendly. The keyboard can only be so big before it loses its usefulness... The US keyboard already has a fine array of characters on it. I would venture a guess that the vast majority of US citizens who own a computer will never have a reason to type the Euro symbol as long as they live... so why should the US keyboard have it? What is needed is a handy way to enter characters that are NOT on it... And it sounds like SCIM is the answer I'm looking for, from another post in this thread. However, as it turns out I already have this installed on my Debian systems at work), and much like the other IMEs I've tried to get working, the documentation seems to be nonexistant (or at least I couldn't find much of anything useful in the 10 minutes I had to look this afternoon). Until then, console apps (and thus the OS) won't be UTF-friendly. Actually, you may find these helpful: http://www.tldp.org/HOWTO/mini/Euro-Char-Support/ http://www.tldp.org/HOWTO/Belgian-HOWTO/configuration.html Particularly the first. While I don't speak Belgian, I did find that the second discussed several ways to configure the system to allow the entry of accented latin characters. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpszxSm5AHaQ.pgp Description: PGP signature
Re: cron and kmessage
On Sat, Jun 24, 2006 at 07:51:58PM -0400, Kamaraju Kusumanchi wrote:
My actual problem is that I want to display a message at specific
times (every 0th, 30th minute of hour) on the user's screen. I
thought I can do this with cron and kmessage.
[snip]
But then it does not display the dialog on the screen. Instead it sends an
email to the user's address with the following message
kdialog: cannot connect to X server
These days the X Window System uses a reasonably decent authentication
scheme (with a silly name), called MIT-MAGIC-COOKIES. When a user
starts their X session, it runs xauth for them to create their session
cookie. You can see these using the xauth command:
$ xauth list
myhost/unix:0 MIT-MAGIC-COOKIE-1 85b25d08e07043401010101010101010
localhost/unix:0 MIT-MAGIC-COOKIE-1 85b25d08e07043401010101010101010
Not that I'm really worried about anyone accessing my display, but I
sanitized my cookie above with the 1010... sequence.
By default, xauth uses the file $HOME/.Xauthority to store this
information. If your user's home directory is not on NFS, or if it is
on NFS and you are using the no_root_squash mount option, your
processes running as root will have access to that file. You can
either add these cookies to your own Xauthority file, or you could
tell the system to use the user's xauthority file by setting the
XAUTHORITY environment variable and the DISPLAY variable in your
script, like this:
export DISPLAY=localhost:0.0
export XAUTHORITY=~user/.Xauthority
kdialog blahblahblah...
You will, of course, need to figure out who is logged in via X. If
you know it will always be a particular person (i.e. yourself), you
can just put that person's username hardcoded in your script, like I
did above. Otherwise, you'll need to figure it out programmatically.
You can do that by using the w command. If the user is logged in
through X, their terminal will show up as something like ':0' in the
output of w, so you can grep on that:
$ w |grep ':0'
09:06:59 up 29 min, 5 users, load average: 0.00, 0.14, 0.19
root tty1 -08:586:01 0.24s 0.24s -bash
user :0 -08:40 ?xdm? 1:22 0.23s /bin/bash
Unfortunately times can also match, since it's quite common for the
sequence :0 to show up in times (like 6:01 in the line for root, which
we don't want). We can fix that though. Normally in the output of w,
the display is shown as :0 or :0.0 with whitespace after the zero.
So, a better pattern to match on (using egrep instead of grep) might be
this one:
$ w |egrep ':0(.0|)\W'
user :0 -08:40 ?xdm? 1:22 0.23s /bin/bash
Now you can use a tool like awk or cut to get just the username from
that line:
$ user=`w |egrep ':0(.0|)\W' |awk '{print $1}'`
Now you have the user's name in the variable $user. But you can't use
the tilde trick with a variable, i.e. if $user is user, the shell
will unfortunately not expand ~$user to the same as ~user. You'll
need to grep the user's passwd file entry and cut it out of that, like
this:
$ grep ^$user: /etc/passwd | cut -d':' -f 6
Now assign that to say, $userhome:
$ userhome=`grep ^$user: /etc/passwd | cut -d':' -f 6`
All together, your script will look like this:
#!/bin/sh
user=`w |egrep ':0(.0|)\W' |awk '{print $1}'`
userhome=`grep ^$user: /etc/passwd | cut -d':' -f 6`
export DISPLAY=localhost:0.0
export XAUTHORITY=$userhome/.Xauthority
kdialog blahblahblah...
If you have multiple displays (i.e. :1.0, etc.) you might need to
change your egrep pattern. If there's anything else weird about your
system, you'll have to figure that out for yourself too... ;-)
Now, if you CAN'T access the user's cookie file for some reason
(having it on an NFS file system being the usual reason), an
alternative might be to use the wall command to write your message to
the console and all logged in terminals... This is the usual way for
the system administrator to communicate with all logged in users.
It's a little bit annoying, because it interrupts what the user is
doing in their terminal, but that is after all the idea. You want to
make sure they see it... If they are doing something like editing a
file in vi, where writing to their terminals is really disruptive,
users can redwraw their terminals by pressing ^L.
--
Derek D. Martin
http://www.pizzashack.org/
GPG Key ID: 0x81CFE75D
pgp3ITRcsNmoh.pgp
Description: PGP signature
Re: What does it mean 'LANG=C'
On Sun, Jun 25, 2006 at 08:01:21PM +0700, Surachai Locharoen wrote: I just want to know 'LANG=C' what does it mean? Normally, I see LANG is set to laguage which exist in the real world such as en, th, fr. The LANG variable sets the user's locale, which tells the system what language and local conventions for things like time, money, numbers, etc. the user prefers to use. The primary importance of this is to tell the system what character set the user is using (and therefore what characters the user can see on terminals, and such.) Modern systems are moving to UTF-8 environments, which makes the language part mostly irrelevant; it can display (almost) all characters in all supported languages, regardless of what language the user is using. However, ancient Unix systems used a locale of 'C', which uses the character set US-ASCII, and sorts things (like directory entries, for example) according to the ASCII sequence of characters. See the man page for locale in seciont 5 of the man pages for details: $ man 5 locale -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgp1wPtyOLlDN.pgp Description: PGP signature
Re: What does it mean 'LANG=C'
On Sun, Jun 25, 2006 at 07:37:51AM -0700, Xeno Campanoli wrote: I've wondered about that. Why aren't modern systems just moving straight to Unicode? Well, as I said, they are. It's mostly the modern PEOPLE who are not... ;-) Debian Sarge is pretty good as far as UTF-8 support, though for people who want to use multiple languages (more than one of which are non-latin languages) input support is still sub-optimal, hard to get working, and extremely poorly documented (as far as I can tell). I also use Fedora Core 4 on most of my personal systems, and I find that to be a little better than Sarge (it's a bit more current). I'm sure the less stable distributions of Debian have the same level of support as Fedora, but for various reasons I won't go into here, I don't use those. While the majority of people in the Windows world have switched to XP by now, there are still a surprisingly large number of people using Windows 98/ME (or even older releases) which don't support Unicode. The same is true in the Unix world... or at least the people using those systems haven't gotten around to updating their environments to use the Unicode support their OS provides. So, it's a complicated issue. Maybe 10 years from now, everyone will finally be using Unicode... but by then we'll probably have some other standard too. ;-) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgptNCA1cBaJh.pgp Description: PGP signature
Re: What does it mean 'LANG=C'
On Sun, Jun 25, 2006 at 10:48:28AM -0500, Ron Johnson wrote: When US keyboards have the Euro symbol on it, then it will have happened. Well, I don't think that is or should be a requirement... I mean, why limit that idea to just the Euro symbol? Why not include the Yen, or the Korean Won, the British pound (they're still using their own money, aren't they?), not to mention the thousands of other symbols used by other cultures... P.S. - How do you enter a Euro symbol from a US kbd into Tbird? Copy-paste from a web page or other source which has it? I keep a file in my home directory with a few common symbols that are hard or impossible to type with a US keyboard: ℉ ℃ € ¥ £ ¤ × ÷ © ® ° ± ² ³ · ₤ ₩ ∞ ￡ ￥ ￦ P.P.S. - How do you do the same from the console? No idea... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgp1WFlifz5oc.pgp Description: PGP signature
Re: What does it mean 'LANG=C'
On Sun, Jun 25, 2006 at 11:54:54AM -0400, Derek Martin wrote: P.S. - How do you enter a Euro symbol from a US kbd into Tbird? Copy-paste from a web page or other source which has it? I keep a file in my home directory with a few common symbols that are hard or impossible to type with a US keyboard: ℉ ℃ € ¥ £ ¤ × ÷ © ® ° ± ² ³ · ₤ ₩ ∞ ￡ ￥ ￦ BTW, there *is* another way... If you have your keyboard configured properly in your XF86Config file, you can type these characters, along with most of the accented latin characters, using some combination of Alt and/or Meta plus the regular keys. Originally I did exactly that, though I don't recall how the keyboard was configured, and it's since changed and I'm unable to do that now. You might have to configure your keyboard as US-International or enable dead keys, or something like that... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpnjN00rjdet.pgp Description: PGP signature
Re: iptables log target logs everything to tty*. Why?
On Sat, Jun 24, 2006 at 01:51:38PM +0200, Erik Persson wrote: [EMAIL PROTECTED]:~# cat /proc/sys/kernel/printk 3 4 1 7 Cool, I didn't realize this file existed in the /proc filesystem. Time to review the documentation... ;-) man proc reveals that the 1 is the lowest value that console log level may be set to. Thats the reson, I guess, that klogd -c 0 did fail. Yup, it's based on the loglevels for syslog. There is no level 0... There might be a slightly easier way... The dmesg command, in addition to dumping the kernel's message buffer to the screen, can set the maximum priority (number) of messages which get logged to the console. For example: dmesg -n 1 This would do the same thing as klogd -c 1 I guess. The main difference is that this method lets you change the level on the fly... you don't need to restart klogd for this to take effect. If klogd is not running, do the kernel messages get saved in the kernel buffer? With normal syslog messages, of course, you would lose them... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpCiP23Zg98K.pgp Description: PGP signature
Re: group ownership of /dev files
On Fri, Jun 23, 2006 at 10:16:26AM +0200, martin f krafft wrote: also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.0454 +0200]: My conclusion is that it seems from a security standpoint, and from an ease-of-administration standpoint, pam_console is the clear winner over both of the other proposed solutions. So yes, when I said pam_console was nice, I meant it, and I stand by that. Have I missed something in my analysis? If I have, I would certainly like to learn what it is. Go ahead then and use it. But please do not make statements about Debian not meeting the requirements of seasoned Unix admins such as yourself. Why should I not make such statements? If Debian is not meeting the needs of people who want to use it, why should the Debian community not strive to meet those needs? Is the Debian community not open to change for the better? Are its developers not open-minded enough to consider that a solution they previously dismissed might not actually better than the one(s) they've proposed? I certainly hope that's not the case. We, as in Debian, are going one path with our system, and while someone might well like to deviate, one thing you cannot say is that we don't reason with every step we take. I never said you didn't... but can you provide a logical reason for discluding support for pam_console? Can you find any fault with my analysis? You may not personally like pam_console, but it appears to be technically superior to all of the debian-supported solutions to the problem of how to provide access to system resources to workstation users -- a problem which lots of sysadmins must wrestle with. So what logical reason is there not to include it? Does Debian not strive to be the best distribution it can be, meeting the needs of as many users as it can? I'm not asking these questions rhetorically, I'm quite serious. And if you have a logical technical argument against pam_console, I'd still like to hear it. Based on the above analysis, I rather strongly disagree. In every way, pam_console seems up to the challenge, though it needs the enhancement I mentioned regarding killing user processes before it is truly ready. Doesn't sound like a solution I'd want on my machines. Fine. But, why? I don't think ...because I don't like it is a very reasoned or sensible justification, but that seems to be the only justification you are willing to offer. This is starting to seem an awful lot to me like unreasoned anti-RedHat prejudice getting in the way of providing solid technical solutions to real problems faced by real users every day... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpe0eTuZslp7.pgp Description: PGP signature
Re: Replying to list
On Thu, Jun 22, 2006 at 11:07:13PM -0700, Steve Lamb wrote: Derek Martin wrote: It is probably the most configurable and most powerful MUA in existence today, making easy many things which should be and making possible many things which are hard or impossible using other clients. While making hard what other clients make trivial and makes it an extremely poor choice for anyone with more than one email address who wants to keep the mail truly separate. I have about two dozen e-mail addresses, and I find Mutt does an excellent job of dealing with them. Perhaps you are just not yet familiar enough with Mutt's features to know how powerful it can be for managing this... It actually provides numerous methods of dealing with that problem. Mutt's good, granted, but it has warts just like them all. Absolutely true, though I don't think this is one of them. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpYo44O5KkIy.pgp Description: PGP signature
Re: group ownership of /dev files
On Fri, Jun 23, 2006 at 02:27:19PM +0200, martin f krafft wrote: also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.1403 +0200]: Why should I not make such statements? If Debian is not meeting the needs of people who want to use it, why should the Debian community not strive to meet those needs? Is the Debian community not open to change for the better? Sure, for the better. In this case, however, you are the only one who thinks it's better. Given that, as you say, there are numerous discussions on the net about it, that obviously can't be true. Let me say that my purpose in pursuing this argument is to understand what the reasons are. I'm not attempting to attack you or Debian for their decision. I'm simply trying to understand it. Thusfar, I haven't seen any logical, technical argument that makes that decision make sense... I never said you didn't... but can you provide a logical reason for discluding support for pam_console? Please go through the numerous discussions on the topic in the list archives. You are not the first to raise this issue, you know? I have already looked at several which you and others have brought up. In every case I've seen so far, I've shown that pam_console is at least no worse than the alternatives, and often actually better. Can you find any fault with my analysis? You may not personally like pam_console, but it appears to be technically superior to all of the debian-supported solutions to the problem of how to provide access to system resources to workstation users Then I suggest you take a look at the code. If the code is bad, it can be fixed. In principle though, the approach that pam_console takes is technically superior to all of the alternatives. You say that Debian has considered pam_console and rejected it for good reasons. I'm trying to find out what those reasons are... If the sole technical objection to it is bad implementation, why didn't the Debian developers decide to simply fix the code, as they have done with so many other projects? People have pointed me at a few discussions, but in regards to each of those discussions, all of the supported methods are actually worse than pam_console, as I've shown. Did you read my analysis, and seriously consider what I wrote? And if you have a logical technical argument against pam_console, I'd still like to hear it. It's an ugly hack that will cause more problem than it's worth. That's not a technical argument. It's simply an opinion for which you have provided no basis. I've managed hundreds of Red Hat systems which used it, made extensive use of it myself, and have encountered no such problems. It does, however, effectively provide access to peripherals to anyone who logs in on the console. Your assertion appears to be baseless. Fine. But, why? I don't think ...because I don't like it is a very reasoned or sensible justification, but that seems to be the only justification you are willing to offer. You are talking about killing processes and you're asking me why? How, for instance, do you want to cope with the situation of letting a second user log in in KDE or Gnome while the first session is locked? Just kill the first session? First of all, my intention was that this extension should be an option, not mandantory. PAM allows the modules to have options... If that option is not appropriate for your installation, don't use it. Even without it, pam_console still is more secure (at least in principle, without considering the actual implementation) than the two alternate solutions the Debian community seems to favor. Secondly, how do you propose to allow more than one user to log into the same console simultaneously? The only way this scenario is plausible is if there is more than one physical console attached to the system, or if the same user wants to start multiple sessions in different virtual consoles; this kind of usage is relatively rare, and in either case that particular feature is obviously not for you. But also in that case, someone is going to lose out on using the peripherals, guaranteed. A technical solution which accepts this idea is possible. pam_console could create a lock file, which it would use to determine whether or not someone was already using (or at least had the rights to use) the hardware. If so, it would not reset the permissions upon a second user's login. This is starting to seem an awful lot to me like unreasoned anti-RedHat prejudice getting in the way of providing solid technical solutions to real problems faced by real users every day... Go ahead and provide the solid solution then. Don't expect others to do it for you. Isn't that precisely what Linux distributions do? They provide solutions for people so they don't have to do it themselves... -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpEWSECNWLMQ.pgp Description: PGP signature
Re: xdm source .bash_profile
On Sat, Jun 24, 2006 at 12:00:03AM +0200, Pavlos Parissis wrote: Hello all, I have been trying to make my X to source the .bash_profile in order to set my $PATH variable. .xsession is the best place to deal with this, but you need to start your X session in this file, or else it will just end. For example, my .xsession file looks like this: #!/bin/bash # start my X session if [ -f ~/.bashrc ]; then . ~/.bashrc fi xrdb -merge .Xdefaults ssh-agent gnome-session This starts gnome, and runs it from ssh-agent. That's a neat trick which makes your ssh agent accessible to all xterms started from within your X session. If you use KDE, replace that with startkde. The key is, once this script ends, so does your X session. If you just source your .bashrc file, your X session will end before it has a chance to start. ;-) Since ~/.bashrc is invoked by no login shell I don't really mind to use this trick. But, I do mind that fact that I have duplicate information, $PATH is set in two files. The usual way to handle this is to put environment initialization commands only in .bashrc, and source .bashrc from .profile (or .bash_profile). Note that you don't want to put commands which generate output in .bashrc -- if you do this, it can cause problems for your ssh sessions (particularly using scp, etc.) which will receive the output of the .bashrc script, and corrupt the data stream. To counteract that problem, only put commands which generate output in .profile (or .bash_profile). HTH -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpfXqpX3IU5Q.pgp Description: PGP signature
Re: xdm source .bash_profile
On Sat, Jun 24, 2006 at 01:22:04AM +0200, Pavlos Parissis wrote: This starts gnome, and runs it from ssh-agent. That's a neat trick which makes your ssh agent accessible to all xterms started from within your X session. If you use KDE, replace that with startkde. Side effect of that approach is that you have to use only one Desktop Environment. Well, not necessarily. instead of starting a desktop environment, you could just start an xterm, by itself, and DON'T run it in the background. From that xterm, you can start your desktop environment on the command line. It's a little bit yucky, but it gets you what you want... But, you have to be really careful. If you close that xterm, your X session will die. The key is, once this script ends, so does your X session. If you just source your .bashrc file, your X session will end before it has a chance to start. ;-) That's explain why it was not working for me the trick to just source the ~/.bash_profile from ~/.xsession without starting a window manager/D.E.. Yup. :( Thank you very much, You're welcome! -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgp1EjHS50Bcc.pgp Description: PGP signature
Re: iptables log target logs everything to tty*. Why?
On Sat, Jun 24, 2006 at 12:58:42AM +0200, Erik Persson wrote: I tried with klogd -c 0 but the messages just kept on coming. It seems that the minimal allowed log level for kernel messages was set to 4 on the router and klogd -c 0 thus didn't change the kernel log level as I thought. This solves the problem since I now know what caused it. I will probably change the iptables log level to debug to get rid of the messages. Did you restart klogd? I don't believe it will change unless you stop the old running klogd and restart it. If you didn't stop the previously running one, the new one you started won't do anything, except exit with an error message, Already running. There might be a slightly easier way... The dmesg command, in addition to dumping the kernel's message buffer to the screen, can set the maximum priority (number) of messages which get logged to the console. For example: dmesg -n 1 This will log only panic messages to the console. IIRC the default level of iptables messages is 5 (warn), so this will prevent the messages from being printed to the console. You can add it to your init scripts somewhere, or your script for starting your iptables rules... If you want to receive kernel messages on the console for priorities higher than warn, you should be able to use up to dmesg -n 4 and still eliminate the messages from being printed. In practice, I find that having the messages logged to syslog is enough, so logging only critical messages works out fine. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpbFObz2EPQL.pgp Description: PGP signature
group ownership of /dev files
Hi folks, If there's a more appropriate place to ask this, please let me know. I manage a large number of workstations which run Debian. Everyone in my organization need to be able to access any of these workstations, and they expect basic services (like sound, for example) to work properly. Red Hat has a nice PAM library that lets people access, say, the sound devices when they log in on the console. Thus anyone who logs in automatically has access to the sound devices. However, this facility appears to be lacking in Sarge. Note: it is not possible for me to add everyone to the audio group. The workstations get all authentication and group memberships from corporate resources which I do not control. And, even if it were possible, it would be a very bad solution given the large number of machines and large number of users; it would be a maintenance nightmare. Conveniently, everyone who needs to access these machines is in a common group. So, barring trying to compile pam_console for debian and making a custom debian package of it, which I don't want to get involved with, the obvious solution, by far the cleanest and most appropriate solution, is to change the group ownership of the necessary devices to that group. Sounds simple, doesn't it? Except that Debian seems to have some mechanism which, at boot time, resets the group ownership of /dev files. Worse yet, there seems to be more than one of them... I found /etc/init.d/makdev AND REMOVED IT, but despite that, the /dev file ownerships are still getting reset at boot time. Thus, whenever the systems are rebooted, users can't use sound. It's understandably annoying to them, which makes it rather annoying to me. ;-) Anyone know how I can make this stop? Or alternately, know a different way to solve this which I have not already discussed? FWIW, as a long-time system administrator of Unix systems in a wide variety of environments, I consider this behavior highly undesireable, and would like to suggest to any developers listening that they consider changing that behavior. It combined with the lack of pam_console or something like it, this behavior makes managing user access to devices quite difficult. If you're managing your own box, it's a simple matter to add yourself to the audio group; but in many different computing environments, that's just not a feasible option. Thanks. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgpHJvM6ybrbx.pgp Description: PGP signature
Re: group ownership of /dev files
On Thu, Jun 22, 2006 at 11:07:37PM +0200, martin f krafft wrote: [pam_console] devices when they log in on the console. Thus anyone who logs in automatically has access to the sound devices. However, this facility appears to be lacking in Sarge. by choice, yes. http://lists.debian.org/debian-devel/2001/06/msg00944.html I agree the post's points are valid... However how is this any worse than adding all the users to the audio group (a solution recommended in that very message, and many other posts on various debian lists)? Either way, this is still possible... In my scenario, everyone who uses these machines would need to be added to the audio group. So there is no gain in security here by comparison. I would argue that pam_console is actually better, because it offers only the temporary ability to do this, and the user had to log in on the console to get the privilege in the first place. Using the group method, EVERYONE in the group can do this at any time, as long as the sound device isn't already open by someone else. Any such user can log in remotely and repeatedly open the sound device whenever any other user releases it... So, I don't see how you can argue that using a group is better than pam_console. And in any event, the only problem it causes is a DoS of that resource, which the system administrator can fix right quick, and can disable the account of the offending user. This is annoying, but it's not really a big deal, and the user can be dealt with in other ways. IIRC pam_console also has mechanisms to prevent it from working for specific users/groups, so there again, it would seem to be a better solution. I might be mistaken on that last point though; it's been years since I had any reason to configure it beyond Red Hat's defaults. But anyway... check out pam_group and /etc/security/group.conf for another approach, which is not secure (read comments), but a little better. Thanks for the tip... this may work, though at a quick glance, again, I don't see how this is better than pam_console. You are probably using udev which creates them after boot. dpkg -l udev Yup. Anyone know how I can make this stop? Or alternately, know a different way to solve this which I have not already discussed? You could help with modularisation of makedev, which will allow you to specify policies for device files. Is udev using makedev, or equivalent? If not, I would think that the better way to go would be to look into configuring policies in udev... In particular, it would be nice if whatever is managing the devices noticed that the device files exist already, and leave them alone if only the permissions and/or ownerships have changed. dpkg -P udev Any potential gotchas to doing that? It might be the right solution for my purposes... you get what you ask for. Now if you're not using devfs but a plain /dev, you should be fine. FWIW, I didn't ask for udev. It appears to be the default... I'll need to read up on udev, and see what it provides. Been meaning to do that for a long time now... ;-) Thanks for your response, and thanks to everyone else who responded. It looks like a real solution to my problem is going to have to wait until I do a little more research, but at least I know what to look at now. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgp2ra1OBTESf.pgp Description: PGP signature
Re: group ownership of /dev files
On Fri, Jun 23, 2006 at 12:41:51AM +0200, martin f krafft wrote: also sprach Derek Martin [EMAIL PROTECTED] [2006.06.23.0017 +0200]: Thanks for the tip... this may work, though at a quick glance, again, I don't see how this is better than pam_console. It does not mess with the filesystem for a start. OK... but how is this a win? One of the reasons devices were implemented as files was to make precisely this kind of manipulation easy. It's simple, efficient, and it works as expected. Let's try to make a fair technical analysis. Think about what problem we're trying to solve: access to physical devices connected to the hardware. Who should be able to access those devices? It the overwhelming majority of cases, the person who is sitting in front of the hardware, i.e. logged in at the console. That person changes each time someone new logs in and logs out. If it were data in a file to which the user needed access, we would just change the permissions on the file. But the point is, devices are just files. They were designed that way specifically so there would be no difference in the way they are treated. Thus, the most obvious, logical, and efficient way to change the access to those resources is to change the permissions on the device file to that of a user who logs in at the console. That's exactly what pam_console does, precisely in the way that Unix was originally intended and designed to do it... As for the security implications of someone logging in at the console and holding the resources hostage: with the pam_console solution, far fewer people can do this (only the last person to log in at the console) than can do so if you just add trusted users to the audio group. In the latter case, anyone in the audio group can execute such an attack, at any time. In that regard, while admittedly still flawed, pam_console appears technically superior to adding users to different groups for each of the device classes. And from a systems management point of view, it involves no administrative overhead, whereas maintaining group files (or other authentication mechanisms like LDAP) can become an administrative nightmare if you have a large number of users. There again, pam_console appears to be superior. Now let's compare pam_console to the other solution that's being offered here: pam_group. In most regards, pam_group actually seems to be very similar to pam_console. However, with pam_group, the user may temporarily assigned to new groups. While they have those group privileges, as the referenced document itself points out, there's nothing stopping the user from making their own SGID binaries that grant them that privilege permanently. Can such a privilege escalation be executed using pam_console? No. pam_console only grants temporary access to a specified resource to a user, by changing the permisisons on the resource to that which the user already has... No additional privileges can be gained in that manner. Here again, pam_console appears to be the winner. [We must ignore the possibility of an unknown priviledge escalation (probably to root) caused by a programming error in the pam libraries themselves; such a bug could exist in either library.] Additionally, while I don't think it currently does this, there's no reason I can think of that pam_console can't be extended to find all of the user's processes which are accessing the devices (or files) it is managing, and kill them after (not before -- race condition) it changes the permissions back. Obviously I already favor this approach to managing the problem, and I think if such an extension were coded up, it would make pam_console a vastly superior solution to the problem compared to any other which has been mentioned here. As far as I can see, that would completely close all of the security holes associated with granting users access to the device files. [Note though that pam_group could certainly be extended in the same way... If I get bored enough, I might just look into coding that up (as an option) for both libraries. Both could probably benefit from a common module of functions that does this.] My conclusion is that it seems from a security standpoint, and from an ease-of-administration standpoint, pam_console is the clear winner over both of the other proposed solutions. So yes, when I said pam_console was nice, I meant it, and I stand by that. Have I missed something in my analysis? If I have, I would certainly like to learn what it is. Why are inquiries on this list about the functionality of pam_console met with such contempt and disdain? Such a response doesn't seem to hold up to technical analysis, and in fact appears to be entirely baseless. There is no solution to your problem, not on a multiuser operating system. Based on the above analysis, I rather strongly disagree. In every way, pam_console seems up to the challenge, though it needs the enhancement I mentioned regarding killing user processes
Re: Replying to list
On Thu, Jun 22, 2006 at 04:04:40PM -0500, Seth Goodman wrote: So getting back to the topic of this thread, insisting that all competent mailers have a 'Reply to List' function, when none of the most common mailers for people trapped in the most widely used operating system have the required feature, is not really helpful to them. For those with this concern, without considering the other points: Mutt is arguably the most competent mailer in existence (or at least one of them) and does have a Reply to List function. It runs on Windows, Linux, and virtually every other major platform in existence. It is probably the most configurable and most powerful MUA in existence today, making easy many things which should be and making possible many things which are hard or impossible using other clients. It's a good choice for anyone who is on a mailing list (or 12), or has a job or hobby that requires a lot of mail processing. It is non-graphical, so it may have certain mild deficiencies related to that, but nicely handles configuration of helper applications for MIME types to compensate. That said... We seem to be saying, in effect, if you aren't smart enough to already use Linux and have a competent MUA, get off this list. That is hardly welcoming to those who are curious. Indeed! While I happen to agree with the sentiment that ideally everyone should use list reply, not everyone knows that such options exist; and even if they do, not everyone has control over what mail client they use. The choice may be rammed down your throat by your corporate IT department, and often is. Also people who are on mailing lists who do have such powerful tools (and complain that everyone else should too) should also know that there are methods available to them of dealing with mail from people who aren't completely clued in. There's no harm in politely pointing out to people that there's a better way... but you should still be prepared to deal with the problem yourself. The fact remains that most people who read their mail on Windows workstations, as I do, _don't_ have a 'Reply to List' button. There are a lot more of them than 'nix systems. In many cases, lack of education is the issue. Such mailers exist for Windows. You just have to know that, care, and get one. But unfortunately, there is no law requiring that anyone do any of those three things... ;-) If you'd like to see that change, as I would, perhaps we could be a little more accommodating and take the operation of their MUA's into account when deciding how this list operates. We are just doing M$'s bidding when we make this mailing list cumbersome for Windows MUA's. This may be a club, but let's not make it an exclusive one. I missed the earlier part of the thread, so I'm not sure what point is being advocated here. I will say that header munging is often requested to combat such problems. The trouble is that header munging often makes otherwise sane mail clients behave insanely (i.e. making it difficult to reply to certain recipients when otherwise it would be easy to select whether to reply to the sender, or to the list, or to everyone in the recipient list; all of which are sometimes called for). The onus should be on the people who choose to run deficient mail clients (even if only by choosing to work at a place that makes the decision for them). They should be the ones who need to correct their recipients if their mailer can't do a good job of doing it for them. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D pgp0n430yjsQZ.pgp Description: PGP signature
automating installs
Hi folks, I am trying to build an automated install image using Debian. It's going pretty well so far, but I've run into a little snag. We have a lot of international users, so it's useful to have all of the supported languages installed and usable. Thanks to the nice folks over on the debian-i18n list, I've figured out a way to make that happen. The snag is, installing all those packages prompts me about ispell dictionaries and such numerous times. I'm aware that I can shut these prompts off by running dpkg-reconfigure debconf, but this again gives me a prompt. Is there any way to shut this off via command-line tools which is non-interactive? I'll want to re-enable a non-interactive mode when the install is finished, also. Thanks for your help. -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
termcap library
I am attempting to install the spice3f5 circuit simulator available from Berkeley. It seems to compile fine, until the end where it loads the main executable, and gives the following error: /usr/bin/ld: cannot find -ltermcap I am using Potato, and I have the termcap-compat package installed. libtermcap.so.2 is in /lib where it should be. Anyone know what I should do to get this admittedly rather old program to build?
