Re: LILO to boot FreeBSD
** On Oct 17, Joel Dinel scribbled:
[snip]
hdd: timeout waiting for DMA
hdd: irq timeout: status=0x58 { DriveReady SeekComplete DataRequest }
hdd: DMA disabled
[PTBL] [1245/255/63] hdd1
How can I tell Linux to leave hdd completely alone ?
try appending 'hdd=noprobe' to the linux kernel boot parameters (settable in
your boot loader's config file)
marek
pgptkb2WhXHqF.pgp
Description: PGP signature
Re: neighbour table overflow
** On Oct 06, Robert Lazzurs scribbled: On Thu, 5 Oct 2000, Marek Habersack wrote: ** On Oct 05, Robert Lazzurs scribbled: I have now compiled and installed a custom 2.2.17 kernel as I thought it might have been a problem with the kernel image that debian provides, but it is not! Any help would be vvvnice :) Check whether you have the lo network interface up. If not - start it. This should cure your problem. marek I have tried, but it does not appear to be setup, have you any ideas on how I can do this? What Debian distro are you using? marek Potato, thanks again - Rab OK. there are two ways of doing it: 1. Check out whether you have the /etc/networ/interfaces file. If it's there, just add the following line at the top of it: iface lo inet loopback After doing so, execute the following command line as root: ifup -a 2. If #1 isn't working for you for some reason, you can use the older approach: Check whether you have the /etc/init.d/network script. If it's there try putting the following lines at the top (below the shebang): ifconfig lo 127.0.0.1 route add -net 127.0.0.0 From now on on every startup the lo interface should be configured and running. You can type those commands without restarting the machine, of course. hope that helps marek pgpLLh1KUj5jh.pgp Description: PGP signature
Re: neighbour table overflow
** On Oct 05, Robert Lazzurs scribbled: Hello, I am a potato user, and I have setup my system fairly minimal, nothing but c/c++ dev, x with icewm, gnome-libs, and apache and exim. I keep getting the above message, but I cannot track the reason, it happens when I access remote sites, for instance, when I ping my self, or mess about with my pop server (I had that setup yesterday, I have trashed my machine once trying to fix this, long story) I have now compiled and installed a custom 2.2.17 kernel as I thought it might have been a problem with the kernel image that debian provides, but it is not! Any help would be vvvnice :) Check whether you have the lo network interface up. If not - start it. This should cure your problem. marek pgpj9WUQ2R2TC.pgp Description: PGP signature
Re: neighbour table overflow
** On Oct 05, Robert Lazzurs scribbled: I have now compiled and installed a custom 2.2.17 kernel as I thought it might have been a problem with the kernel image that debian provides, but it is not! Any help would be vvvnice :) Check whether you have the lo network interface up. If not - start it. This should cure your problem. marek I have tried, but it does not appear to be setup, have you any ideas on how I can do this? What Debian distro are you using? marek pgpo6PIrwcIcF.pgp Description: PGP signature
Re: Too many messages
** On Sep 19, Rob scribbled: Heh. guys this is sort of off-topic (sorry) but its so typically me that I signed up for like four of the topics on the mailing list and im revieving like 200 messages a day, which I just dont have time to read, how can I cancel all of the lists except for one? Heh sorry :x It's, like, to read what's under, like, _every_ message posted to this list. Hint, look below :P Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null ^^^ marek pgpNCZWISSpaG.pgp Description: PGP signature
Re: Helix Gnome Evolution 0.3
** On Jul 29, Hans scribbled: At 12:03 PM 7/28/00 -0400, Ethan Pierce wrote: Hi, I was reading today on slashdot about Evolution 0.3. They have a download link for the tar.gz file. I was wondering if the apt-get utility will work if I use the spidermonkey.helixgnome.com source for the update? Has anyone else tried this? Thanks -Ethan -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null I don't want to start a war here, but what's so great about Evolution? It looks more like a regression to me. It imitates M$ in more than one way: it looks like it, has the same bloat factor and packs way to many features in a single frame. Where is the innovation? I switched from KDE to Gnome because I saw smarter programs being developed by the Gnome team, but after seeing Gnumeric and now this Evolution I start to doubt. Nobody forces you to use Evolution. The advantage of such software is that it provides a functionally and visually equivalent to proprietary software while being 100% free. I suppose that advantage is obvious. You can look at it as on a marketing/support factor. If any of your customers would come to you and say hm... I would switch to Linux, but I kinda like the M$ Outlook. If Linux had something like that Now you will be able to say Voila! Evolution - right here for you! :-). Besides, the product will no doubt be dozens of times more secure than any of the M$ incarnations of Outlook. There was an awful flamewar some time ago on debian-devel/debian-project regarding non-free software. One of the arguments of one of the sides was that as long as we cannot provide the users with 100% free equivalents to the proprietary/non-free software we cannot remove the non-free section from Debian. Well, Evolution is one (big) step towards the goal of having only free software in your machine. That said, I will only state that I won't use Evolution for my own mail, since I prefer other MUAs, but I find Evolution a great thing to have in our (read: the free community) software pool :-) marek pgpdJ4bcDwsnv.pgp Description: PGP signature
Re: Helix Gnome Evolution 0.3
** On Jul 29, Andre Berger scribbled: [EMAIL PROTECTED] (Marek Habersack) writes: it as on a marketing/support factor. If any of your customers would come to you and say hm... I would switch to Linux, but I kinda like the M$ Outlook. If Linux had something like that Now you will be able to say Voila! Evolution - right here for you! :-). Besides, the product will no doubt be dozens of times more secure than any of the M$ incarnations of Outlook. When my department switched to Linux (CorelLinux w/ KDE), our intent was to provide a familiar UI for the designated Ex-Windows users. (We purged that perverted slink stuff quickly in favor of woody w/ Gnome for technical reasons. And KDE can't handle 800x600 in a way that would make us happy.) The user fraction on their side were also seriously disappointed from Linux Windows... because they have to mount removables now: But you have to admit that Windows is easier to use, repeated by two dozen people every once a while we show up. I guess it's psychologically important for the man on the keyboard not only to use SW that makes a difference on the system level but visualize the difference on the GUI level. This helps not to confuse apples and pears, and also won't force us to compete with MS's featuritis. I agree with you 100% - and Evolution as well as any other GNOME software makes exactly that difference - the UI has different appearance, so that one can immediately tell what is being used. My point wasn't that the software must/should be a GPL-ed mirror of the other software, no - my point is that the transition curve for the newcomer to the Linux OSes should be minimized by providing the most common features/screen layout _by default_ in the software s/he is to use. You cannot and should not force anyone to learn anything completely new when he is just a mere user, not programmer, developer or die-hard hacker, whatever. I don't know whether you have ever had anything to do with support services but if you would, then you'd know how hard it is to persuade common users of software to using anything else they familiar with. And that's the whole point I want to make - they want software which is similar enough to what they have used before for them not to spend weeks in learning everything anew. marek pgpkt5XWv9ze9.pgp Description: PGP signature
Re: Helix Gnome Evolution 0.3
** On Jul 29, Ethan Pierce scribbled: The main reason I am psyched for evolution is my girlfriend cant grasp pine or mail. She needs something graphical. If I can avoid booting windows2000 so she can read her email in outlook I will be happy as a clam...hence evolution is the perfect solution for the ms llamas :) And this is a perfect reasong for Evolution existence :-)), and a confirmation of what I wrote before. But, wrt. graphical clients - there are more than just Evolution - Netscape Communicator, balsa (also a GNOME app), heck - even the (X)Emacs VM can be considered graphical if used with XEmacs :)) and probably many more I haven't heard of :) marek pgpFk8rv9HLTH.pgp Description: PGP signature
Re: Helix Gnome Evolution 0.3
** On Jul 28, Kent West scribbled: Ethan Pierce wrote: Sorry all, the sources.list line should read: deb http://spidermonkey.helixcode.com/evolution/distributions/Debian/ ./ I thought the . in ./ was a typo, so I didn't include it. I got a bunch of dependency errors. So I went back and added the . and tried again; still got dependency errors. Oh well, guess I'll wait a while to give 'er a spin Try including the following line in addition to the above: deb http://spidermonkey.helixcode.com/distributions/debian unstable main it should work just fine now marek pgp8fvNWh5EDW.pgp Description: PGP signature
Re: Bash script question (was: Re: Netscape 4.73 wrapper broken)
** On Jun 24, Mark Phillips scribbled: Corey Popelier [EMAIL PROTECTED] wrote: Yes I have this problem also. I assume we shall await a fix. And use Mozilla in the meantime :) [snip] And the problem seems to be with a syntax error at the line for f in (cd $d;ls -1 . | sort); do According to man bash, the (cd $d;ls -1 . | sort) is a compound You shouldn't rely on what bash supports or not. The Debian shell scripts are supposed to be POSIX-compatible, and not everything bash implements is POSIX. command where the stuff in brackets is executed in its own shell. So what this line seems to be trying to do, is to go to a certain directory, get a sorted listing of the files there and then go through them one by one, executing . $d/$f for each of them. What is the . command??? I thought it was the current directory? It's the 'source' command. It takes its argument and interprets the file as a shell code - you might think of it as sort of dynamic linking for scripts. Anyway, the reason for the syntax error is with the definition of a for loop in bash. From man bash: for name [ in word ] ; do list ; done Again, don't rely on bash being the /bin/sh. Debian scripts cannot do that. Now word is a list of blank separated words I believe, so it does not allow the (cd $d;ls -1 . | sort) construction to be used here. So somehow we need to find an alternative. I don't use that script, but I think adding $ before the first bracket would do the trick. Any ideas? Upgrade :)) - it will have been fixed when you read those words most probably :)) marek pgp8wKXz6IzN9.pgp Description: PGP signature
Re: Bash script question (was: Re: Netscape 4.73 wrapper broken)
** On Jun 24, Mark Phillips scribbled: Peter Kovacs [EMAIL PROTECTED] wrote: On Fri, 23 Jun 2000, Peter Kovacs wrote: I'm sure that a fix has already been posted, but this works for me (replace the code above with this): for d in /usr/lib/netscape/base-4/wrapper.d ; do cd $d; for f in `find -maxdepth 1 -type f`; do . $d/$f done done Wow. I just realized how incredibly incorrect the code is. Well, it works for me. YMMV though. I'd wait for an official fix, or fix it yourself if the above doesn't work. What does YMMV stand for? Your Mileage May Vary for f in $(cd It seems to work sort of, but I don't understand why! The $(...) construct is a replacement for the old `...` construct which means execute the comands between the single quotes (or the $(...) sequence) and replace the expression with the output of the command sequence. The command sequence is executed by a subshell, that is no side effects occur to the current shell (pwd, environment etc.) And what is the . $d/$f supposed to do?? Read my previous posting. marek pgpfE5R1srHJ7.pgp Description: PGP signature
Re: True Type Support of Xfree86 4.0
** On Jun 11, kmself@ix.netcom.com scribbled: On Sun, Jun 11, 2000 at 10:13:34PM +0800, Alex Kwan wrote: I have seen the release notes of XFree86 4.0 said that it will supported the True Type Fonts. Is it mean that if I have installed the 4.0R and I don't need to install the xfs or xtt server to support true type fonts any more? That's the theory. I haven't installed XF86 4.0 myself. It's practice. YOu just have to enable an appropriate driver for the font format. Works like a charm. One doesn't need xtt anymore. marek pgpgbwaWvHnzs.pgp Description: PGP signature
Re: Anyone having trouble upgrading Helix-Gnome?
** On May 26, Phillip Deackes scribbled: For most of yesterday and today I have been trying to upgrade to the latest version of Helix-Gnome (based on Gnome 1.2). Following instruction exactly (the usual apt-get update, apt-get dist-upgrade with /etc/apt/sources.list pointing to Woody and spidermonkey.helix.com) the connection keeps timing out. I eventually downloaded gtk-themes_0.1-helix5_i386.deb after many stop starts, (it is over 16MB) only to find the message from apt-get MD5Sum mismatch and E: Some files failed to download. Starting apt-get dist-upgrade again, the whole damned file starts downloading again. On a dial-up link this is beyond a joke Am I doing something wrong? No, I've got the same problem - the helix servers reset the connection and the transfer rate is 7Kb/s tops (compared to 80Kb/s previously). I suspect this is a problem with their servers being overloaded after announcing R2 with GNOME 1.2. Enough to say that I've been trying to download 30Mb for the last 18 hours... marek pgp2yNocIAFHf.pgp Description: PGP signature
Re: freshmeat running on windoze?!
** On May 20, Sven Burgener scribbled: Hi debians According to www.netcraft.com/whats , freshmeat.org is running on windoze? Is this really the case!? How come? Is this for real? Yup, it is for real. http://www.freshmeat.org is running WinNT, but http://www.freshmeat.NET is running Linux, as one might expect :) marek pgpP556IUesDm.pgp Description: PGP signature
Re: freshmeat running on windoze?!
** On May 20, Sven Burgener scribbled: Hi I realised shortly after that I tried the wrong TLD. My fault. I immediately posted a cancel message to the list thereafter. I don't have it in my inbox yet... Nevermind :)) But whilst we're on that subject, how would such an OS Port 80 scan be done not using this web-front-end?! There are at least three easy ways to check what operating system runs on the remote machine (let's assume it's got the HTTP port open): 1. nmap -O -p 80 host.name.com You don't want to scan them :), that's why the -p 2. telnet host.name.com 80 HEAD / HTTP/1.0 newline newline here comes the information from the server 3. queso -p 80 host.name.com Actually, nmap uses the same method to check the fingerprint of the remote system and is, IMO, much better in that respect. Well, these are the three easiest methods :)) marek pgpAgP7QjI25L.pgp Description: PGP signature
Re: freshmeat running on windoze?!
** On May 20, Sven Burgener scribbled: There are at least three easy ways to check what operating system runs on the remote machine (let's assume it's got the HTTP port open): 1. nmap -O -p 80 host.name.com You don't want to scan them :), that's why the -p What's the -O option? For some reason, I can't find any info for it; I am missing nmap's man page(!) Full info comes right your way :)): -O This option activates remote host identification via TCP/IP fingerprinting. In other words, it uses a bunch of techniques to detect subtleties in the underlying operating system network stack of the computers you are scanning. It uses this informa tion to create a 'fingerprint' which it compares with its database of known OS fingerprints (the nmap-os-fingerprints file) to decide what type of system you are scanning. If you find a machine that is misdiagnosed and has 5 NMAP(1) NMAP(1) at least one port open, it would be useful if you mail me the details (ie OS blah version foo was detected as OS blah version bar). If you find a machine with at least one port open for which nmap says 'unknown operating system', then it would be useful if you send me the IP address along with the OS name and version number. If you can't send the IP address, the next best thing is to run nmap with the -d option and send me the three fingerprints that should result along with the OS name and ver sion number. By doing this you contribute to the pool of operating systems known to nmap and thus it will be more accurate for everyone. straight from the nmap page :)) l8r, marek :) pgpup4yjssksn.pgp Description: PGP signature
Re: freshmeat running on windoze?!
** On May 20, Sven Burgener scribbled: Hi Marek Full info comes right your way :)): Cheers a lot! But how come I don't have that? :*! There's sort of an empty man page describing that other infos can be found locally under /usr/doc/nmap/... *My* nmap doesn't recognise the -O flag. I am unsure about its version, but I'm running slink, so maybe that's why? What are you running? Or do I maybe need to install another package? You probably got the 1.x version, get 2.x - it will be fine :)) marek pgpbfvl8r8Egy.pgp Description: PGP signature
Hmm... what gives with that mail??
Hi *, Take a look at the message below. I have just received it from the debian-user list. There would be nothing strange in it if not for the fact that the person who posted it (apparently from the wcom.com domain as seen in the full logs) appears to have an address [EMAIL PROTECTED] - that is in _my_ domain :)). The problem is that neither no bolan or debian.vip.net.pl exist! Our mailer is not an open relay, the user posted it from the wcom.com domain (see the attached full logs). I wonder whether the other people on the list received posts from [EMAIL PROTECTED] regards, marek - Forwarded message from Bolan Timothy Lewis Meek [EMAIL PROTECTED] - Date: Wed, 17 May 2000 15:27:11 + From: Bolan Timothy Lewis Meek [EMAIL PROTECTED] Subject: Re: GRACIAS SI ES POSIBLE!!! (translation) To: debian-user@lists.debian.org Cc: [EMAIL PROTECTED] Here is a translation for you anglophones: Estimados Amiggoos Esteemed friends Soy un usuario fiel de Linux y me gustria Recibir una I am a faithful user of Linux, and it would please me to receive a camiseta de Regalo si es posible. yo vivo en T-shirt as a gift if it possible. I live in Cali-Colombia Calle 2c # 65b25 b/ El Refugio [No translation necessary, as this is an address.] Gracias.. [Thanks...] Att: Freddy Andres Mera Freddy, es posible obtener mejor respuesta si eras un usuario fiel de Debian... ;-) (Freddy, it is possible to obtain a better response if you are a faithful user of Debian.) -- Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] /dev/null - End forwarded message - From [EMAIL PROTECTED] Wed May 17 17:50:58 2000 Return-Path: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Received: from mail.vip.net.pl (mail.vip.net.pl [195.216.103.131]) by jester.vip.net.pl (Postfix) with ESMTP id DF451102F3 for [EMAIL PROTECTED]; Wed, 17 May 2000 17:50:58 +0200 (CEST) Received: from murphy.debian.org (murphy.debian.org [216.234.231.6]) by mail.vip.net.pl (Vip-Net Mailer) with SMTP id 50DD53F3E for [EMAIL PROTECTED]; Wed, 17 May 2000 17:50:57 +0200 (CEST) Received: (qmail 28751 invoked by uid 38); 17 May 2000 15:48:49 - X-Envelope-Sender: [EMAIL PROTECTED] Received: (qmail 28691 invoked from network); 17 May 2000 15:48:48 - Received: from pmesmtp02.wcom.com (199.249.20.2) by murphy.debian.org with SMTP; 17 May 2000 15:48:48 - Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id [EMAIL PROTECTED] for debian-user@lists.debian.org; Wed, 17 May 2000 15:47:50 + (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id [EMAIL PROTECTED]; Wed, 17 May 2000 15:47:49 + (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id [EMAIL PROTECTED]; Wed, 17 May 2000 15:47:20 + (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id [EMAIL PROTECTED]; Wed, 17 May 2000 15:47:20 + (GMT) Received: from omta3.mcit.com ([166.37.204.5]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with ESMTP id [EMAIL PROTECTED]; Wed, 17 May 2000 15:47:01 + (GMT) Received: from ngndebian1 ([166.35.145.181]) by omta3.mcit.com (InterMail v03.02.07.05 118-131) with ESMTP id [EMAIL PROTECTED]; Wed, 17 May 2000 15:47:53 + Received: from bolan by ngndebian1 with local (Exim 3.12 #1 (Debian)) id 12s5j5-fr-00; Wed, 17 May 2000 15:27:11 + Date: Wed, 17 May 2000 15:27:11 + From: Bolan Timothy Lewis Meek [EMAIL PROTECTED] Subject: Re: GRACIAS SI ES POSIBLE!!! (translation) To: debian-user@lists.debian.org Cc: [EMAIL PROTECTED] Message-id: [EMAIL PROTECTED] Resent-Message-ID: [EMAIL PROTECTED] Resent-From: debian-user@lists.debian.org X-Mailing-List: debian-user@lists.debian.org archive/latest/92562 X-Loop: debian-user@lists.debian.org Precedence: list Resent-Sender: [EMAIL PROTECTED] Resent-Date: Wed, 17 May 2000 17:50:57 +0200 (CEST) Status: RO Content-Length: 714 Lines: 23 pgpGFnGrrKNIp.pgp Description: PGP signature
Re: Hmm... what gives with that mail??
** On May 17, brian moore scribbled: On Wed, May 17, 2000 at 06:33:04PM +0200, Marek Habersack wrote: Hi *, Take a look at the message below. I have just received it from the debian-user list. There would be nothing strange in it if not for the fact that the person who posted it (apparently from the wcom.com domain as seen in the full logs) appears to have an address [EMAIL PROTECTED] - that is in _my_ domain :)). The problem is that neither no bolan or debian.vip.net.pl exist! Our mailer is not an open relay, the user posted it from the wcom.com domain (see the attached full logs). I wonder whether the other people on the list received posts from [EMAIL PROTECTED] They would if they had a host named 'debain.YOUR.DOMAIN.COM'. The thing is I _don't_ have debian.VIP.NET.PL and still I got the message with such address. Sendmail (and probably other smtp servers) tries to canonify names in headers. This is a semi-helpful process, but it usually is correct to do. (See RFC1123, section 5.2.18, which mandates using fqdn's which is why sendmail, trying to be nice, tries to fix partial names it sees.) I use postfix and I suppose it does the same. In the situation where the lookup fails I suppose postfix appended my domain name even though the host with such derived name doesn't exist. Sites without a machine named 'debain.whatever.com' (ie 'nslookup debian' fails) will leave it as '[EMAIL PROTECTED]'. Not what happened here... Even more obvious of the same thing is people who send mail as just 'username' which gets canonified as [EMAIL PROTECTED] by each recipient. (Spammers do this reasonably often judging from how often our users complain about it.) The original poster apparently used Exim, which does canonicalize local user names, unless it is misconfigured. Looks like the original sender needs to fix their mail setup to use the fqdn. he, or one of the several relays that lie between him and the outer world... marek pgpVqwZmteBOH.pgp Description: PGP signature
Re: Hmm... what gives with that mail??
** On May 17, Mark Brown scribbled: On Wed, May 17, 2000 at 07:59:01PM +0200, Marek Habersack wrote: [EMAIL PROTECTED] canonicalised to [EMAIL PROTECTED] I use postfix and I suppose it does the same. In the situation where the It does. lookup fails I suppose postfix appended my domain name even though the host with such derived name doesn't exist. It's a straight textual substitution. Look at the trivial-rewrite manual page for details. One thing you can do about things like this is to reject unresolvable sender domains (perhaps accepting them from local hosts if you do canonnicalisation or anything for them). I reject unknown clients. Remember that the mail was received by my mailer from murphy.debian.org - so I suspect that's where the problem with accepting unknown domains lies. Even more obvious of the same thing is people who send mail as just 'username' which gets canonified as [EMAIL PROTECTED] by each recipient. (Spammers do this reasonably often judging from how often our users complain about it.) The original poster apparently used Exim, which does canonicalize local user names, unless it is misconfigured. Given that his host was called debian I strongly suspect that that's all he's got for a hostname. it wasn't - that's another surprise. Apparently (look at the mail headers I attached to the original post) his host is called 'bolan', and lies on a LAN with DHCP-assigned addresses, just as well as its smarthost (166.35.145.181) which then passes mail to 166.37.204.5, then to 166.38.58.143, then it hits the firewall which forwards the mail to murphy.debian.org. Note that the X-Envelope-Sender had a value of [EMAIL PROTECTED] which VRFY at dgesmtp01.wcom.com reports as a valid local alias (SMTP reply 251), but mail sent to that address bounces... Looks like the original sender needs to fix their mail setup to use the fqdn. he, or one of the several relays that lie between him and the outer world... Most of those relays appear to be the same box. Hmm... maybe, but I'd rather say there are at least 2 hosts between him and the outer world. marek pgpmpnBJIIvWu.pgp Description: PGP signature
Re: socket programming
** On May 12, Sean 'Shaleh' Perry scribbled: On 12-May-2000 Brett Fowlkes wrote: I am writing a server that accepts telnet connections. I am using basic sockets to do so and do not use inetd. I cannot figure out how to disable the echoing to screen for the password. I have tried everywhere else, this is my last resort. a) read the telnetd / telnet source b) look at how programs like login do it it boils down to you setting flags for the device. And for good socket tutorials, info etc. you can visit those two addresses: http://www.private.org.il/tcpip_rl.html http://www.lowtek.com/sockets/ regards, marek pgpdl0w032Cvg.pgp Description: PGP signature
Re: socket programming
** On May 12, Sean 'Shaleh' Perry scribbled: a) read the telnetd / telnet source b) look at how programs like login do it it boils down to you setting flags for the device. And for good socket tutorials, info etc. you can visit those two addresses: http://www.private.org.il/tcpip_rl.html http://www.lowtek.com/sockets/ or read the best book on earth -- Unix Network Programming (volume 1) by W. Richard Stevens. If you want to write netowrk code, read his books. Covers ipv4 and ipv6, common pitfalls, etc. I second that 100% - these books are excellent (although quite expensive :). But those above URLs contain some valuable information as well, together with real world examples. A good resource altogether. marek pgpBpaaz7Dx6S.pgp Description: PGP signature
Re: daemons -- who needs'em?
** On Apr 28, Brad scribbled: i merely think i have a screwy setting here or there that's needlessly duplicating log messages. settings are the bane of my linux existence, still... Now, stop right here for a while. syslog isn't Linux - it's a common software, created quite elsewhere. Don't blame anybody for something which isn't their fault. Don't like the duplicates? Voila - man syslogd.conf and configure the beast. Or get syslogd-ng - it's much more versatile. Linux is a _kernel_, not an _operating system_. And syslog is a piece of software used on almost _all_ Unices out there. A little harsh, wasn't that? By settings are the bane of my linux Yup, it was... sorry existence i believe the original poster mean all settings, not specifically those of syslog-- e.g kernel config, module configs, sendmail/exim/etc config, samba config, ftpd config, and so on. Looking at it now, you're probably right - but show me a system which doesn't require setting anything and I'll tell you that it's a piece of junk... That said, the only way to get good at configuring is to read the docs and configure. Exactly. Make mistakes, correct them and _learn by example_ - it's the only way to get _anything_ working really good. Manuals, courses and whatnot are all groovy things, but without practice they are next to useless. Docs are just a startpoint, that's it your philosophy is also mine--install diddly and add what you need-- the gap between us is a hefty base of knowledge, which is why i get to bug you folks about this kind of thing: you got it, i'm gettin' it. I see it a bit in a different light. Install some pre-selected set, read all the docs you can, find your ways around and then reinstall the system from scratch, with the freshly acquired knowledge in mind - this other time you'll know what to install and what not to install. And, remember that every single of us here went through much the same process sometime in the past :))) (and thank God that you've got dselect and apt and dpkg : Nah, reinstall isn't necessary. Just dpkg --purge the useless stuff. I've even managed to repartition my box without reinstalling ;) (... backups) I think the reinstall is actually a good thing for a newbie - it is a good thing to use install in its verbose mode and look at the packages _knowing_ this time what they're for. i do wonder what the newer installs are like though... They're much better, IMO :)) marek pgpXzK5Id979R.pgp Description: PGP signature
Re: daemons -- who needs'em?
** On Apr 28, Joey Hess scribbled: Marek Habersack wrote: rwhod = server for 'whois [EMAIL PROTECTED]' I didn't write that :)) :P useless crap (IMHO) But I still hold on to this point of view - completely useless No, rwhod doesn't have anything to do with whois. How useful it is is ia matter of opinion, I happen to like this a lot: [EMAIL PROTECTED]:~ruptime box up 142+20:37, 0 users, load 0.00, 0.00, 0.00 dragonup 107+15:51, 1 user, load 1.14, 1.05, 1.01 kite up 55+10:32, 3 users, load 1.17, 1.11, 1.11 paper down7+16:08 silkdown1+19:10 But maybe just because I like my uptimes. I don't like portmapper hanging around, and this is an RPC-based service.. marek pgpprRlM8Wmeu.pgp Description: PGP signature
Re: daemons -- who needs'em?
** On Apr 28, w trillich scribbled: there's still a AWFUL lot of overlap! No there's not. Please give the people who wrote linux some credit for sense. i saved the output from tail -50 /var/log/syslog tail -50 /var/log/daemon.log and did a 'diff' on them: of fifty lines, there were only 8 sections needing an edit: 1 delete (11 lines) and 7 adds, affecting a total of eleven differing lines between the two logs; (50-11)/50 = 78% overlap. i think the linux folk are absolutely amazing, nonetheless. i used to have visions of coding grandeur... but now i sit back and gape at how even microsloth trembles at what linux can do. i merely think i have a screwy setting here or there that's needlessly duplicating log messages. settings are the bane of my linux existence, still... Now, stop right here for a while. syslog isn't Linux - it's a common software, created quite elsewhere. Don't blame anybody for something which isn't their fault. Don't like the duplicates? Voila - man syslogd.conf and configure the beast. Or get syslogd-ng - it's much more versatile. Linux is a _kernel_, not an _operating system_. And syslog is a piece of software used on almost _all_ Unices out there. since there is little reason a syslogd program should not be portable. Therefore, it makes excellent sense to make it be in its own daemon. Which just passes log messages on to syslogd, so there is no code overlap. my bad. i didn't mean _code_ redundancy (heavens! did you think i was accusing linus of generating microsquish code?) but rather log-output Linus isn't the only person behind Linux, just for the record. redundancy... See a few lines above. Given the list you posted, you seem to have installed a great deal of daemons onto your debian system without knowing what they do. That is not a good idea. It's the type of thing redhat people seem to do, but in debian there is no point in doing so. Install a minimal system, add daemons and other packages one at a time as you find the need for them. i started all this debian stuff about a month ago from the 2.1 cd, merely following on-screen prompts and installing as little as i could (debian cd installs a micro-set of stuff from which you reboot; instead of a shell, you're dumped into a 'select what you intend to use this computer for' interface [workstation/xwindows? or web/file server?] and then after lengthy installs, the subsequent reboot appears to have removed the selector utility so that you CAN'T add more stuff en masse... or at least a newbie surely couldn't). This is just to make it easier for you to start up. But it doesn't free you from reading documentation and understanding what software serves what purpose. It's a common sense to browse the list of installed and running software and think what you really need. It's all in the documentation. And dselect is your true friend in that task. based on my infinitesimal knowledge of commands and facilities at the time, i learned from 'man' and localhost/doc that 'alien' would handle rpm files, and 'dpkg' would install them. thanks to this list i found out that those methods have been steamrollered by the more powerful apt-get method. And good for you! There's no reason to blame anyone for installing so much crap on your machine - this is not your fault nor anybody else's. It's just a simple way to get you started. your philosophy is also mine--install diddly and add what you need-- the gap between us is a hefty base of knowledge, which is why i get to bug you folks about this kind of thing: you got it, i'm gettin' it. I see it a bit in a different light. Install some pre-selected set, read all the docs you can, find your ways around and then reinstall the system from scratch, with the freshly acquired knowledge in mind - this other time you'll know what to install and what not to install. And, remember that every single of us here went through much the same process sometime in the past :))) (and thank God that you've got dselect and apt and dpkg : marek pgpsOiOhRHHuS.pgp Description: PGP signature
Re: daemons -- who needs'em?
** On Apr 27, w trillich scribbled: ever wonder what all those background processes are for? me too, and i still do. if you have some answers, please post them for us newbies. # ps t\? PID TTY STAT TIME COMMAND 1 ?S 0:06 init [2] parent of all the processes in your system. 2 ?SW 0:00 [kflushd] Not a real process - a kernel flush daemon (actually a kernel thread) Runs periodically to flush the block device buffers 3 ?SW0:00 [kswapd] Same as above, but for the swap activities. Synchronizes swap information. 4 ?SW 0:00 [md_thread] 5 ?SW 0:00 [md_thread] You probably don't need these two. They're auto-mounter threads AFAIR 9757 ?S 0:00 /usr/sbin/apache Your HTTP server. 1319 ?S 0:01 update On newer kernels it's not needed anymore. Performs the same function (more or less) as the above k*d daemons. 1885 ?S 0:00 /sbin/syslogd System logger. Writes to files what applications send to the system log. 1887 ?S 0:00 /sbin/klogd A partner to the above daemon which takes care of the kernel logging. 1894 ?S 0:00 /sbin/kerneld Daemon to load the modules on demand. In newer kernels not needed anymore. 1897 ?S 0:01 /usr/sbin/named Nameserver (a DNS server) - in that case it's BIND 1918 ?S 0:00 /usr/sbin/exim -bd -q30m Your MTA (Mail Transport Agent) or, in M$ nomenclature, an SMTP server 2002 ?S 0:00 /usr/sbin/rwhod RPC-based remote who server. 2001 ?S 0:00 /usr/sbin/rinetd A version of inetd that redirects requests somewhere else than this machine. 2018 ?S 0:00 /usr/sbin/afpd -n server 2020 ?S 0:00 /usr/sbin/papd Don't know these two :)) 2026 ?S 0:00 proftpd (accepting connections) ProFTPD ftp server running in standalone mode 2031 ?S 0:00 /usr/sbin/atd Scheduled job spooler (for the 'at' command) 9758 ?S 0:00 /usr/sbin/apache 9756 ?S 0:01 /usr/sbin/apache 9759 ?S 0:00 /usr/sbin/apache 9760 ?S 0:00 /usr/sbin/apache 9761 ?S 0:00 /usr/sbin/apache Clones of the parent (above) HTTPD process. Apache is a multi-process architecture server. 2206 ?S 0:00 /sbin/portmap Portmapper for the RPC-based services (kinda a dispatch for them) 2215 ?S 0:00 /usr/sbin/inetd The normal internet superserver. It takes care of starting your services that aren't ran in the standalone mode. 5922 ?S 0:00 /usr/sbin/cron A cronjob server. Something like a scheduler but a periodic one, unlike atd which executes something 'at point' - once. [snip] inetd = listens for network connections hands them off to appropriate processes proftpd = ftp server apache = httpd server named = dns nameserver (xlate 'www.site.org' to '123.45.678.90') exim = email stuff cron = periodic script-runner (try crontab -e) atd = like cron; but for running scheduled 'at time' commands update = flushes disk buffers now then so if ever you crash (remember windows? macos?) you'll lose less. these i can GUESS at: *logd = system loggers: syslogd and klogd both log important messages to your log files. we need them _both_ because... well... um... Because syslogd handles the userspace messages, klogd handles the kernel messages. kerneld = linux 2.0 and earlier--some voodoo regarding modules (dynamic module loading in 2.1+ [aka 'kmod'] makes this obsolete?) yup rwhod = server for 'whois [EMAIL PROTECTED]' useless crap (IMHO) rinetd = like inetd, but different? nah, a redirector - do you really need it? afpd = portion of appletalk network protocols, maybe? papd = some more appletalk stuff? hmm, dunno, perhaps? :) portmap = something to do with Remote-Procedure-Call? precisely marek pgpcVSNURPlmn.pgp Description: PGP signature
Re: daemons -- who needs'em?
** On Apr 27, w trillich scribbled: to paraphrase bob hope's theme--thanks for the summaries! 2206 ?S 0:00 /sbin/portmap Portmapper for the RPC-based services (kinda a dispatch for them) portmap = something to do with Remote-Procedure-Call? precisely can i ditch it? is it essential somehow? If you use NFS or other RPC-based services then it's needed, otherwise - ditch it *logd = system loggers: syslogd and klogd both log important messages to your log files. we need them _both_ because... well... um... Because syslogd handles the userspace messages, klogd handles the kernel messages. there's still a AWFUL lot of overlap! Naah :), not really :) rinetd = like inetd, but different? nah, a redirector - do you really need it? as in, for firewall/ipmasq router? (if so, yes!) Not that. It simply redirects requests from port A on your machine to port B on another machine (possibly with no routable IP). If you don't do such kind of trickery, you can get rid of it. how about ypbind? what's that, and why? It's a bindery service for the former YP (Yellow Pages) SUN service (now NIS, NIS+) - you probably don't need it unless you keep user's data on a NIS server. marek pgpn57AbgSeK6.pgp Description: PGP signature
Re: WordPerfect Office 2000 - Opinions?
** On Apr 13, Carl Fink scribbled: [snip] Or am I better off getting the commercial version of 8? Do you need a spreadsheet? A presentation program? Just a quick question - any luck with using non ISO-8859-1 fonts/keyboards with WP9?? I never succeeded installing ISO-8859-2 or whatever other than -1 on WP8... marek pgp07OEM8duXo.pgp Description: PGP signature
Re: /dev/mixer hosed by potato upgrade...
* rich said: I have also seen some messages about /dev/dsp being gone, and xwave says: cannot access audio device... Any ideas? Are you using ALSA? pgpqLlyeCNLmq.pgp Description: PGP signature
Re: update-menus problem with potato
* Sean Johnson said: wow, don't know how I missed that ... thanks. Anytime :))) marek pgpOFpgPBeW6V.pgp Description: PGP signature
Re: update-menus problem with potato
* Sean Johnson said: A quick fix is to remove (or move) the /usr/lib/menu/xbase-clients file ... as its format is evidently fscked. Even quicker is to edit it and add a backslash after every 'hints=something' line. marek pgpAGDbUCzWKV.pgp Description: PGP signature
console characters display problem
Hi *, I have a problem with console fonts display. The scenario is as follows: I load a font from /usr/share/consolefonts (namely iso02grf.psf which comes with embedded SFM), load the appropriate keyboard map (pl02.map) and expect to see the Polish diacritics on the screen. However, this is not the case. Instead I see the old characters from the CP437. Now, using showcfont reveals that the characters are where they should be! A simple experiment: showkey --keymap I press some keys that should produce the Polish diacritics (e.g. RtAlt-l should give me E with a hatch) and I see the hex keycode (in the sample case it's 0xb3) and, instead of seeing the character I expected, the display shows me a character that in the table produced by showcfont corresponds to one at the position 0xc7. Funnily enough, the character on position 0xb3 in the same table is exactly the one I wanted to see! This happens not only when I type, but also when I try to read some text with Polish diacritics. The machine runs latest potato. The thing is that at home, with the same potato, everything works just fine! I tried all combinations of consolechars invocations - with and without ACMs and SFMs and it still doesn't display as it should even though the keyboard produces correct codes... Anyone has any idea what it might be? :) marek pgpRayydHieXI.pgp Description: PGP signature
Re: /etc/limits
* Ethan Benson said: Also: I still don't know of any way to set the Virtual Mem usage of a shell without using ulimit (bash) or limit (csh)! Note that it does not appear to be an option in /etc/limits or in pam's limits.conf. Anyone know how to do it? There must be a way. ulimit does not really protect at all against someone malicious since they are perfectly free to un-ulimit themselves, this is where pam_limits is helpful, it enforces the hard limit and it cannot be ulimited past that. Not only pam_limits is useful. You can use the capabilities of the shadow package to put the ULIMIT system value in the user's entry in the passwd/shadow database. marek pgpJDVkItpcDt.pgp Description: PGP signature
Re: /etc/limits
* Jim B said: On Mon, 10 Jan 2000, Ethan Benson wrote: ulimit does not really protect at all against someone malicious since they are perfectly free to un-ulimit themselves, this is where pam_limits is helpful, it enforces the hard limit and it cannot be ulimited past that. Hmmm. How would a user unlimit himself without changing his shell? If he stays in a single bash or csh shell, I don't know how he could do that. He can't, true. But shell-based limits aren't particularily good way of setting limits. They are by definition bound to one kind of shell - csh or bash or whatever. In case you, or the user, decideds to change his shell, you loose all the limits. PAM and/or shadow utilities (or lshell) are much better. [snip] OTOH if you're talking about someone who switches his shell to get around the limits, that's my whole point. I need to know how to set shell-independent limits. Yes you can do that with PAM, but I still don't see a PAM limit on virtual memory. Is there one there? Compute the ULIMIT value and put it in the commen't field of the user's record in the password database (ulimit=ULIMIT_VALUE). Then the login process will set the limits regardless of the shell. And if you worry about the user changing shell during the session - don't. The child process whether spawned or executed, will inherit the limits from its parent. marek pgpobnffszbRZ.pgp Description: PGP signature
Re: /etc/limits
* Jim B said: On Tue, 11 Jan 2000, Marek Habersack wrote: He can't, true. But shell-based limits aren't particularily good way of setting limits. They are by definition bound to one kind of shell - csh or bash or whatever. In case you, or the user, decideds to change his shell, you loose all the limits. PAM and/or shadow utilities (or lshell) are much better. Correct. But this is the crux of this whole thread. I don't see any way, *other than* shell limits, of setting max Virtual Memory usage. The other resources yes, VMem no And the pam_limits 'as' + 'rss' + 'data' + 'memlock' + 'stack' parameters? They all give you fine-grained control over the user's memory. marek pgpkS8gsSzPfY.pgp Description: PGP signature
Re: /etc/limits
* Jim B said: On Tue, 11 Jan 2000, Marek Habersack wrote: And the pam_limits 'as' + 'rss' + 'data' + 'memlock' + 'stack' parameters? They all give you fine-grained control over the user's memory. OK, you're right. I had tried some of the PAM limits previously (one at a time) and none of them alone was sufficient to restrict an account's memory usage from devouring the machine using a particular exploit I'd gotten hold of. At the same time, restricting the user's virtual memory The 'virtual memory' is a quite broad term as you can see : (ulimit -v) was able to stop the exploit, while none of the other ulimit options did. Therefore I thought I was unable to limit the max vmem using PAM. Thank you for pointing out to me that I can. :) My pleasure :) One last thing... the original question also was, how do slackware and RedHat set the max vmem usage without using ulimit, /etc/limits, or PAM? Would you happen to know this off-hand? I thought maybe it was compiled into the login binary but I downloaded the source and their patches and didn't see any reference to it. Friends of mine have a slack 7 and an RH6 box, RH has PAM enabled but no limits configured, while the slackware machine has no /etc/limits, /etc/pam.d, or /etc/security. Yet when I log in, my virtual memory limit is set to 2105343 KB. Is that something From a quick look, it's in the bash shell for those distributions. When I changed my shell on one RH 6.1 server I got unlimited memory. marek pgp3ovjkk7d8V.pgp Description: PGP signature
Re: AOpen video card question
* Phil Brutsche said: capability does it mostly work (in this case, the X screen bulges outward at the sides. This is a fairly common card. I finally replaced it with an older Diamond Stealth 3D 2000. But surely someone has had success setting it up? There is nothing wrong with what you're doing with that video card; I have have two myself, and have the same problem. I haven't found a workaround. I had a similar problem with the much older card - ALI2301. The screen was scrambled as well, but calling SVGATextMode restored the screen. It seems that with some cards X-Window don't restore the registers correctly on exit. marek pgpSyPt2wSniR.pgp Description: PGP signature
Re: su no longer working after dist-upgrade
* aphro said: i got that when my ulimits were too strict, try killing processes to free up resources (see ulimit for more info) either that or you may be out of memory.. I reported the problem to the packages' maintainers (su and sudo) but apparently the problem of su and sudo not resetting resource limits to those of the target account is not that grave as I expected. su and sudo will leave your rlimits be as you su(do) to another account - a major bug, IMHO, but that's just HO nothing else. marek pgpCO53JtUajd.pgp Description: PGP signature
su, sudo and resource limits
--zYM0uCDKw75PZbzx Content-Type: text/plain; charset=us-ascii Hi *, I was just wondering - how one trying to avoid logging as root as much as possible can do his tasks successfully if su and sudo don't reset resource limits when the privileged command is executed? See the below figures: COMMENT: limits of a privileged account (one allowed to su and sudo to root) jester:~ limit cputime unlimited filesizeunlimited datasizeunlimited stacksize 8192 kbytes coredumpsize0 kbytes memoryuse unlimited descriptors 1024 memorylockedunlimited maxproc 256 openfiles 1024 jester:~ COMMENT: the limits after 'sudo -s -H' jester:~# limit cputime unlimited filesizeunlimited datasizeunlimited stacksize 8192 kbytes coredumpsize0 kbytes memoryuse unlimited descriptors 1024 memorylockedunlimited maxproc 256 openfiles 1024 jester:~# COMMENT: after 'su -s -' jester:~# ulimit -a core file size (blocks) 0 data seg size (kbytes) unlimited file size (blocks) unlimited max locked memory (kbytes) unlimited max memory size (kbytes)unlimited open files 1024 pipe size (512 bytes) 8 stack size (kbytes) 8192 cpu time (seconds) unlimited max user processes 256 virtual memory (kbytes) unlimited jester:~# Now, let's assume I want to restart some daemon or, better, to run dselect and install upgraded packages - it might result in restarting some daemons. Let's further assume I do it using sudo. Everything's fine until I look in the log files and see that e.g. postfix reports - couldn't allocate more file handles... It took me a while before I noticed WHY in heavens did it report that - it turned out that albeit it was started as root the resource limits of the user who invoked sudo to restart the postfix session apply to this particular postfix instance! Now, postfix is just an example and the above limits aren't that restrictive, but what happens if one limits e.g. number of open files to 45, max processes to 10 and then uses sudo or su to restart some daemon? Hmm... looks like we might have a problem - if a service is meant to run as root or as some other user then the resource limits for THAT user or root should apply, unless I'm mistaken. marek --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.1 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEAREBAAYFAjhqIVUACgkQq3909GIf5urrrwCdGTOiFt6AHxPnQR0dSNd+YBaA q04Anjyi+/WCF156wzy8vH6qn6JhzeVU =P8Zl -END PGP SIGNATURE- --zYM0uCDKw75PZbzx-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] ---
Re: PVM
* Blazej Sawionek said:
I found myself too stupid to execute Python examples, so I decided to turn to
PVM (I was told it could also do the task I need), but during installation of
pvm and pvm-dev
I got the following warnings:
ldconfig: warning: /usr/lib/libtcpwrapGK.so.1 is not a symlink
ldconfig: warning: /usr/lib/libomnithread.so.2 is not a symlink
ldconfig: warning: /usr/lib/libomniORB2.so.6 is not a symlink
ldconfig: warning: /usr/lib/libomniLC.so.2 is not a symlink
Now I can't compile nor run PVM examples. Does it mean I have to gove up?
Funny you asked about PVM :)). I don't know the answer for your problem, but
I have one myself - pvm installs, pvmd runs just fine, but spawning a new
process is a disaster... A stupid program which does NOTHING at all
(attached) allocates as much memory as it can. I even ran it as root - just
to test how it will behave. Within 1min from the startup it allocated 570MB
of memory (on a 512MB RAM machine :) and kept doing it happily :). The
loadavg jumped to 10 and was increasing. I killed pvmd and the process and
everything came back to normal. Launching the program as a regular user
allocated mere 140MB memory (which was the limit for that user). What gives?
Can anybody explain to me what's wrong? I'm completely new to PVM.
thanks,
marek
#include stdio.h
#include stdlib.h
#include pvm3.h
#define GROUPNAME ouzo
#define OUZO_TAG 10
#define VERBOSE 1
#define MSG_NEW 1
void msg(char * text)
{
if (VERBOSE) fprintf(stdout, text);
}
int main(int argc, char **argv)
{
int mytid;
int myinstance;
int message[2];
int send_to;
int grpsize;
int max_instance;
int found=0;
int tid;
int i;
char text_message[100];
mytid=pvm_mytid();
msg(Joining to goup ouzo.\n);
pvm_joingroup(GROUPNAME);
msg(Checking if I am first.\n);
grpsize=pvm_gsize(GROUPNAME);
myinstance=pvm_getinst(GROUPNAME, mytid);
switch (grpsize)
{
case 1: msg(I am first so I initiate the ring.\n);
max_instance=myinstance;
send_to=myinstance;
break;
default:
msg(Ring is already set.\n);
msg(Trying to join the ring.\n);
msg(Searching for the process to connect to.\n);
for (i=0; (i==myinstance) || ((tid=pvm_gettid(GROUPNAME, i))=0); i++);
//przygotuj wiadomosc
pvm_initsend( PvmDataDefault );
message[0]=MSG_NEW;
message[1]=myinstance;
pvm_pkint(message, 2, 1);
pvm_send(tid, OUZO_TAG);
break;
}
do
{
msg(Listening..\n);
pvm_recv(-1, OUZO_TAG);
//obsluga przychodzacych wiadomosci
//rodzaje przychodzacych wiadomosci
//MSG_STD - normalny broadcast - do wyswietlenia i do wyslania dalej
//MSG_NEW - poszukiwanie miejsca w ringu dla nowego procesu
//MSG_LAST_UPDATE - update numeru ostatniej instancji w ringu
// zakeszowac i przeslac dalej
//MSG_TERMINATE -- przeslac dalej i zakonczyc program.
} while (1);
/*
if (instance argc==2 !strcmp(argv[1], terminate))
{
printf(terminating ring\n);
pvm_initsend(PvmDataDefault);
message=-1;
pvm_pkint(message, 1, 1);
pvm_send(0, MESSAGE_TAG);
pvm_exit();
}
if (!instance)
{
//i am the first one ... who the fuck is alice ?
//czekam na komunikat o nastepnym przylaczonym procesie
pvm_recv(-1,MESSAGE_TAG);
pvm_upkint(message,1 , 1);
switch (message)
{
case 1: //niech to bedzie przylaczenie nowego procesu
case -1: //to bedzie ring terminate
printf(terminating ring - instance %d, instance);
pvm_exit();
case 2: //to bedzie normalna wiadomosc;
pvm_upkstr(text_message);
break;
}
}*/
msg(Leaving the Group ouzo.\n);
pvm_lvgroup(GROUPNAME);
pvm_exit();
return 0;
}
pgp3kM5ztg1Rx.pgp
Description: PGP signature
Re: Is Corel Off Topic ?
* [EMAIL PROTECTED] said: Just to keep it off topic, I also have BeOS 4.5.2 installed (along with Windows Debian) and it is great! Nice blend of *nix and Mac-land. It only suffers from a lack of drivers and software. Just like Linux a few years ago (there, back on topic). Are there ANY means to get a test drive copy of BeOS?? marek pgpYsMjsUddIe.pgp Description: PGP signature
Re: file permisions in /etc
* Evan Moore said: I have been reading about securing my linux box and it mentions making /etc readable only by root. Would this mess up anything by making making all of the /etc file permisions 600? Hmm... Is it Microsoft Security Bulletin you've been reading? :))) Seriously, securing /etc in that way would break some 80% of programs out there on your Linux box. Take /etc/passwd for one - (g)libc looks up users in that file (unless you use the DB databases), /etc/group - ditto, /etc/services, /etc/Muttrc, shell global startup scripts and dozens and dozens of others. Making /etc 600 is an excellent example of security by obscurity - a very poor security measure. There *are* config files which should be readable only by root and are used only by programs running as root. There are also files which are read only by a specific program ran with a specific user's rights. These you can make 600 and chown to the user that has to access them. If you really insist on hiding the contents of the /etc directory from an average user and still allowing the programs to access their config files set the /etc permissions to 711. marek pgpVckekQYpJK.pgp Description: PGP signature
Re: suidmanager
* Pollywog said: On 12-Nov-1999 Martin Fluch wrote: Report it as a bug (wishlist items) ... I just keep a backup copy of suid.conf and overwrite the new version after I have done a Debian upgrade. That was the easiest way to deal with it without editing the file after every upgrade. Don't make my mistake :) - I didn't RTFM enough - check out suid.conf(5) :)) marek pgp3cGfvRVaQb.pgp Description: PGP signature
Re: suidmanager
* Martin Fluch said: On Wed, 10 Nov 1999, Hans Gubitz wrote: Is suid.conf the right place to change permissions for files (here: xcdroast)? Which scripts change suid.conf? Where can I read about suidmanager? The suid.conf file is used to track programs with special permissions, so that is easy to see, if they are changeing. Speaking of suidregister... I find it annoying that it resets the settings I have modified by hand - for example I want the screen utility to be available only for the group 'screen', the tracertoute, fping, nmap and more to be available only to the 'adm' group. The suid.conf file is a great way to do such modifications, but not when they are reset everytime the package in question re-registers itself. To get around it, I have just prepended to the packages' names a letter M and every time suid.conf is modified by the postinst script, I just move the M packages block to the end of the file and run suidregister by hand. While it works, it is really annoying. What do you think about slightly modifying the suidregister procedure NOT to modify already existent entries? Or perhaps, as an alternative, provide a means to localize the settings by including suid-local.conf file AFTER processing of the suid.conf file? marek pgpfdteg8vgxs.pgp Description: PGP signature
Re: Ftp problem.
* Marcin Kurc said: Install wu-ftpd or proftpd, or whatever you like and check your inetd.conf. Current proftpd (mainstream probably) fails to honour the UserAlias directive, so that logging in as anonymous is not possible. That's with anon servers, as to the normal access perhaps you should check whether the user in question has a shell which is listed in /etc/shells. What do the logs say? marek pgpFZwBtY2nip.pgp Description: PGP signature
Re: Root password
* Jens Ritter said: Seth R Arnold [EMAIL PROTECTED] writes: I haven't tried this myself... but, I seem to recall that if you pass linux single on the boot line (at the lilo prompt, etc..) it will boot into a single-user mode; within that you should be able to passwd root. This will ask for a password, too. You have to reboot using a floppy and edit /etc/passwd manually. No, you don't have to do that. It's enough if you start linux with the following command line: single init=/path/to/your/shell marek pgpaRJqnygbxf.pgp Description: PGP signature
Re: Linux checks only 8 chars of the password...
* Ben Collins said: (atleast after today it will be, once the new shadow is installed). Hmm... is that mean that we're gonna switch to the same passwd suite as RH, for example? Too bad... the current passwd has many useful switches (-l -u being two of them...) No, RedHat does not use all of the shadow tools (it's a mix of shellutils, util-linux and shadow). We are staying with shadow, but PAM enabled. Yes. My statement doesn's stand anymore :)) - since I asked it, I upgraded and was really glad that the old tools are there just with the PAM support added. marek pgpkNoYMpVkCf.pgp Description: PGP signature
Re: Linux checks only 8 chars of the password...
* Gernot Bauer said: Good morning, I was wondering, why Linux only checks 8 characters of the It's not a Linux invention, it's the limitation of the Unix DES method of encrypting passwords. login-password. I use a much longer password and would like my system to check everything of it. Is there a flag I can set that the whole password is verified? Just take a look at the /etc/login.defs and read the description of the MD5_CRYPT_ENAB. Setting this option to on makess the passwd suite use the MD5 digest encryption algorithm which doesn't have the limitation of DES. marek pgpXP1RXVfks5.pgp Description: PGP signature
Re: Linux checks only 8 chars of the password...
* William T Wilson said: On Mon, 13 Sep 1999, Gernot Bauer wrote: I was wondering, why Linux only checks 8 characters of the login-password. I use a much longer password and would like my system to check everything of it. Is there a flag I can set that the whole password is verified? You're stuck with it. The format of the password file only has room for 8 characters of meaningful data. This is a holdover from ancient times, I Hmm Where did you take that information from? Just use MD5 instead of DES. The DES limits password length to 8 chars. marek pgpZH5eeccb0J.pgp Description: PGP signature
Re: Linux checks only 8 chars of the password...
* Ben Collins said: login-password. I use a much longer password and would like my system to check everything of it. Is there a flag I can set that the whole password is verified? Just take a look at the /etc/login.defs and read the description of the MD5_CRYPT_ENAB. Setting this option to on makess the passwd suite use the MD5 digest encryption algorithm which doesn't have the limitation of DES. Please note that in potato, the MD5 is enabled via the /etc/pam.d files I was referring to the current state of stable/unstable. It uses shadowutils package and that in turn uses /etc/login.defs (atleast after today it will be, once the new shadow is installed). Hmm... is that mean that we're gonna switch to the same passwd suite as RH, for example? Too bad... the current passwd has many useful switches (-l -u being two of them...) marek pgpADpic2WzT6.pgp Description: PGP signature
Re: Netscape crashing - Why do we have to rely on Netscape?
* Bill said: Hello, Actually its http://www.operasoftware.com or http://opera.nta.no and the project for opera for linux is under project magic Opera is an excellent browser, but has one (important IMO) disadvantage - it doesn't fully support HTML 4.0 (or rather it didn't support it the last time I checked) - e.g. the layers don't work at all... That's one of the reasons where netscape wins. marek pgpRFQtpi8PLa.pgp Description: PGP signature
Re: Soffice
* Manoj Srivastava said: thomas when opening.. If you please could let me know which package thomas i shall downgrad or upgrade to get it work again i would be thomas very glad since i use soffice everyday.. I am not sure, but quite possibly the issue may be the libc upgrade? I havfe heard rumors that so broke when upgrading from RH 5.2 to 6.0, and the major change there too was libc. It's certainly a case of the libc6 upgrade. I didn't see the beginning of this thread, so I don't know which version of SO you are talking about. I will assume that it's 5.1 - the latest release. SO5.1 requires you to have glibc2.0 while the current potato uses v2.1 of the library. You don't have to downgrade anything at all - it's sufficient to do some wizardry with the SO5.1 binaries and the .so loader. Below is a full recipe on how to do that (tested by me yesterday after downloading a fresh copy of SO5.1 :)): 1. Get the libc6_2.0.7.19981211-6.deb and install it to some directory in the /usr/local tree (e.g. /usr/local/glibc2.0) 2. Do ln -sf /usr/local/glibc2.0/ld-2.0.7.so /lib/ld-2.0.7.so 3. Get some comfortable binary editor (hexeditor is a good choice) 4. Unpack the soffice .tar file as usually 5. Unzip the so51inst/office51/setup.zip to a separate directory 6. Copy the so51inst/office51/setup.ins to the same directory where you put the files extracted in the previous step. 7. Change the case of all the files in the directory to lowercase: for x in [A-Z]*; do mv $x `echo $x | tr A-Z a-z` done 8. Open the setup.bin file in the binary editor, find the string /lib/ld-linux.so.2 and replace it with /lib/ld-2.0.7.so *** MAKE SURE YOU PUT TWO NULL CHARACTERS AFTER THE NEW STRING *** 9. Start X-Window and open an xterm window 10. Now execute (while still in the directory the setup.zip was extracted to): LD_LIBRARY_PATH=/usr/local/glibc2.0:/lib:/usr/lib:./ ./setup 11. SO5.1 installation starts. Enter the path where you extracted the original soffice .tar when prompted for the location of the install files. 12. After the setup finishes successfully go back to the shell prompt and then switch to the bin/ subdirectory of the location where you installed the Office. 13. Unpack the attached tar.gz file in this subdirectory (sorry, couldn't make a diff because I haven't saved the originals :(() 14. Repeat the step 8 for every .bin file in the directory. If everything went well (e.g. if I didn't misled you :))) you should now be able to use SO5.1 without problems. marek soscripts.tar.gz Description: Binary data pgpYQ9bKzEsAb.pgp Description: PGP signature
Re: lost the root password
* Shukuko Yono said:
I need to know whether there are any methods of finding the root password
There are none. The standard Unix passwords are encrypted using a one-way
encryption algorithm using so the only way to test for password correctness
is to encrypt the provided password and compare it to what's stored in
/etc/{shadow,passwd} or elsewhere (that's assuming you're not using any
password servers, one-time passwords etc.).
for my machine. I lost the root password, but I still have access to the
machine as a different user.
Do you have physical access to the machine? If so, just use your Debian
rescue disk, start it until you see the initial Select Monitor Type screen,
then switch to the 2nd console, press ENTER. Now, mount your usual root
partition as /mnt (or whatever :)) and edit /etc/shadow (or /etc/passwd if
you don't use shadow support) - remove the characters between the first and
second colons:
root:0irgffeYNn/ku:10787:0:9:7:::
^ remove this
(sample entry)
save file and reboot as you usually did. The root account has
no password now - log in, change your password and NEVER forget it again :))).
If you have no physical access to the machine, you're out of luck I'm
afraid...
good luck,
marek
pgptheypPLj8t.pgp
Description: PGP signature
Re: telnet access control
* venu said: how is this done ? i have done it once before.. but don't remember how...is it thru inetd.conf ? Nope, see /etc/securetty and man 5 securetty and if i need to restrict number of simultaneous logins (total and for a particular user).. how do i do it ? read /etc/limits and man 5 limits (look for the L: option) best wishes, marek pgpBocTU2cQX7.pgp Description: PGP signature
Re: Netscape crashing -- a lot.
* Philip Lehman said: I had that problem, the fix (for me at least) was deleteing my ~/.netscape Dunno why, but somthing get corupted. Hmmm... this is the first suggestion that has worked for me! i still get bus errors trying to login to dhs.org, but i haven't gotten it to crash on closing a window yet. I just tried that from a new user account and had no problems crashing I tried it as well but, alas, it helped only partially. The problem I have is as follows: 1. Open Netscape Navigator (not Communicator) 4.x and load any page which requires authentication. 2. Type your login and password and tap OK 3. Netscape closes the window and dissappears without ANY error message Now, after removing the ~/.netscape as suggested before, the above scenario doesn't happen anymore. Success! But only until I open ANOTHER Netscape window and try to log into some authenticated page again. After #2 above both windows shut down and vanish from the face of the earth. In my case the pages requiring authentication were the freshmeat.net lounge one and a local Roxen server configuration interface. marek pgp8aqHkxo4kW.pgp Description: PGP signature
Re: Protecting root security
* Tommy Malloy said: Doesn't the fact that I can go to any Linux box with an install disk or cd and gain root access mean that the all Linux systems are fundamentally insecure? Perhaps the install process could be changed so that root password, or some other verification system is required, before a reinstall is permitted. It is true that compromising a system this way requires unfettered access to the box. However as Linux is used more and more in commercial environments this issue will need to be addressed. Hmm... I think that you've got the idea a little bit wrong. An administrator must have such access to the server in case something with the system goes wrong and the only way out is a rescue disk. But, note what I have said - An administrator. Servers should be kept away from the reach of the normal users and, for that matter, of the administrator himself - I'm talking about physical access. There's no need, in normal everyday administrator's job, to access the server physically - he can use either a terminal connected directly to the server or some other, freely chosen, means of connecting to the server. With the latest linux kernels you can even have a console on a serial port, so there IS NO NEED to make the server PHYSICALLY accessible. Physical access was always a security issue and one seriously concerned with it will simply disallow acces to the server. And if we are talking about Linux WORKSTATIONS then just don't put a floppy drive into the case... regards, marek pgpKxaIo6t9KP.pgp Description: PGP signature
Re: Protecting root security
* [EMAIL PROTECTED] said: I suppose it you used cfs (as another poster suggested), you could keep someone from reading your disk. But you couldn't keep them from wiping it clean with fdisk and being generally destructive. I'm not a security guru, but I think it's still one of the most important rules to remember: physical access = null security. As I look at the companies I've worked for in the last few years, they have all been aware of this. I don't think Linux is going to take a hit for this in the corporate mindset. And what's different about Linux? It can be installed on a machine mounted in a rack-mount case closed in a secure compartment and managed through a terminal connected via the serial port - if you really need to have direct console access... regards, marek pgpHvASJuzt7R.pgp Description: PGP signature
Re: Protecting root security
* Ben Collins said: from this type of access is to use some sort of secure fs (cfs and secure loop devices with encryption come to mind), also check into sfs (sorry, no URL's for these). This has a downfall of the fact that the machine cannot boot without user interaction (some one to authenticate or supply the password for the filesystem). Isn't that too much ado? No physical access is the cure - serious approach to security requires NO PHYSICAL ACCESS to the server machine. regards, marek pgpBlEFrpZYnE.pgp Description: PGP signature
Re: Protecting root security
* David B.Teague said: Doesn't the fact that I can go to any Linux box with an install disk or cd and gain root access mean that the all Linux systems are fundamentally insecure? Absolutely. Any system to which physical access is allowed, then the system is vulnerable to a sufficient knowedgable cracker. One doesn't have to be cracker at all :))) - just boot from the rescue floppy then do mount /dev/hda1 /mnt; vi /mnt/etc/shadow and voila :))) The system is yours :) Perhaps the install process could be changed so that root password, or some other verification system is required, before a reinstall is permitted. A physical lock is better for security. Absolutly yes! An effort such as this is now made: when the system crashes requiring a manual fsck, the root password is required for system maintenance. Of course - it's been there for years and if the user thinks that pressing Ctrl-D to bypass it will do anything good to him, he's wrong - the system starts up in a multi-user mode and prompts for the login/password in a usual way. The only way to go aroud it is booting from the rescue floppy/cd It isn't much, and I find this irritating on my test machine. You can easily turn it off by forbidding sulogin be spawned at startup. It is true that compromising a system this way requires unfettered access to the box. However as Linux is used more and more in commercial environments this issue will need to be addressed. I have used machines that have a 'firmmware' password, PCs provide this, as do many machines. If you allow physical access, one can disconnect the battery from the CMOS, and eliminate the password. Hmm... not always true - NVRAM can be used to disable such an action and even the PCs now have NVRAM. There seems to me to be nothing you can do to provide security against entry if you allow physical access. That's true. Someone on this list said, approximately: A secure system is turned off and sealed in concrete. Just line WIndows NT which has the C2-level security certificate if it has no modem, NIC or any means that allow connecting to it from the outside : regards, marek pgpB4H8dcPfE3.pgp Description: PGP signature
Re: Protecting root security
* Koyote said: so that root password, or some other verification system is required, before a reinstall is permitted. It is true that compromising a system this way requires unfettered access to the box. However as Linux is used more and more in commercial environments this issue will need to be addressed. If you think about it- this is no different than windows: power off, insert cdrom or disk one and power on. I don't think that there is any good answer for this. Workarounds abound, for the paranoid: you can wire a hidden switch that must be reset by hand after a power off (uses a small electromagnet to maintain on status) that controlls power to all drives. You can lock the computer, so that no one can get to the drives. You can setup a computer that is not bootable from cdrom, and remove the floppy drive (install it when you need to do a full install.)...(and no, I have no idea how to make the cdrom unbootable on a linux pc. I'll learn sooner or later.) If one wants to go through so much trouble istead of disallowing physical access, he can spend several $ to buy a device which requires a magnetic, or chip card to gain access to any device in the machine. The chip cards use a one-time password scheme to prevent password spoofing - I think DEC sells such devices, but don't quote me. Such device has one disadvantage - the server won't reboot on its own when anthing fails - it will wait till someone with enough privilege comes and inserts the chip card to finish the reboot process. It can be overcome by using a watchdog hardware card which would be connected in such a way, that the security system would allow full system reboot ONLY if initialized by the watchdog hardwar. But still, it's much less security than putting the server away from anybody's hands. If someone wants to workaround these safety features, they can just dismount your hdd and leave, anyway. Exactly. If you are talking about having a password resident in your boot sector or some such soft password, I just come in and boot a floppy that deletes it before loading your system. Sort of. One-time passwords can help. regards, marek pgpxCStBp7Y1N.pgp Description: PGP signature
Re: Protecting root security
* Ben Collins said: machine cannot boot without user interaction (some one to authenticate or supply the password for the filesystem). Isn't that too much ado? No physical access is the cure - serious approach to security requires NO PHYSICAL ACCESS to the server machine. Tell that to people who have their servers in a co-located isp. My Well, I know such ISPs but they all offer (for more money, of course) mounting your server in a rack - and that's secure. server does not have a floppy, but my tape backup is piped through mcrypt so no one can just grab the tape and pull out all of my secure files. Remember, a trusted physical environment is not always present. Unfortunately... But people who have their servers at their workplace can, and should, make sure no physical access is possible. regards, marek pgpfAl7CG2YpQ.pgp Description: PGP signature
Re: Protecting root security
* Rune Linding Raun said: you can by a REAL server eg Compaq server line which can be locked completely and only unlocked by a license disk or a bootpasswd Yes, that's true, but still the server is incapable of rebootig on it's own - it still requires human attendance at that process. And it's a no-no in a real world. regards, marek pgp4WVLKbIhPk.pgp Description: PGP signature
Re: LinuxBerg??
* Person, Roderick said: Has anyone checkout linuxberg.com. I went there to check out some themes and such, but everything I follow is a windows theme. I even downloaded the LINUXBERG theme and it for win95. That cool since I'm at work and using NT, but what is the deal. I can't seem to find anything fro linux. I'm I just having a brain dead day? Hmm :. It's there :)), just check out one of these (there are, of course, more): http://www.linuxberg.com - it will point you to the nearest repository http://icm.linuxberg.com - this is the one I use, it's in Poland, fast connection. cheers, marek pgpYsGdM2GK2R.pgp Description: PGP signature
Re: mutt Reply to: header???
* Paul Nathan Puri said: How do I set up mutt so that the Reply to: header is in the messages? It's easy. Create a .muttrc file in your home directory, then put the following string somewhere in it: my_hdr Reply-To: [EMAIL PROTECTED] I had a professor tell me he could not respond to my messages once because he couldn't hit Reply to: Does this make sense? I noticed I don't have No :))) It doesn't make sense :))) Unless your professor uses some exotic MUA (eerr... eg. M$ Outlook which sometimes doesn't know what to do :))). If there's no Reply-To: header in your message, MUA will use the address as shown in the From: header. Hmm... there are cases when the From: header is missing, but such mail is spam, and I'm sure you didn't send spam to your professor, or did you? :) greetings, marek pgpzt6yDye2vb.pgp Description: PGP signature
Re: configuración de redes
* William R Pentney said: On Thu, 22 Apr 1999 [EMAIL PROTECTED] wrote: Me gustar?a obtener ayuda sobre: ?C?mo puedo instalar una red con linux? Lo necesito urgentemente Gracias [basically: How do I install a network with Linux?] Sugero balsa. Es un colleccion de programas que usa el protocolo SMB. Sugero que se subscribe a [EMAIL PROTECTED] tambien; pueden darle mas ayuda. Mi espanol es muy pobre. :-) Puedes tambien tratar a buscar a los HOWTO (NET-3 HOWTO) en espanol. Por lo que yo se, son algunos trasladaciones de esos textos. Lamentablemente no puedo decirte donde encontrarlos :((. Por lo bueno, es mejos si mandes tus mensajes en la lista que William te ha indicado arriba. Si necesitas mas ayuda, puedes escribirme en personalmente :))) marek pgpmTb3Wg68rP.pgp Description: PGP signature
Re: Self-extracting compressed binaries in Linux?
* William R Pentney said: Is there any program that can create compressed self-extracting executables a la PKLite in Linux? Anyone know of any? Just curious. One of the best I found on the net is exepak. Here's it's LSM file: Begin3 Title: EXEPAK executable file compressor for Linux Version:1.1 Entered-date: 8-27-97 Description:EXEPAK compresses binaries but keeps them executable, like the old DOS PKLITE program. Works on any Linux binary. Archive includes source and 80x86/ELF binary. (There's a memory/speed penalty of course :) Keywords: compression compress exepak pklite Author: Adam Ierymenko [EMAIL PROTECTED] Maintained-by: Adam Ierymenko [EMAIL PROTECTED] Primary-site: http://w3.one.net/~api/exepak/ Alternate-site: Original-site: Platforms: Linux-ELF Copying-policy: public domain, no warranty End You will find it on any sunsite mirror in the utils/compress directory. It's really fast and efficient, I do recommend it if you need such a thing. marek pgpQO0u9trsmy.pgp Description: PGP signature
Re: Where is /etc/rc.d/rc.local on Debian?
On Tue, 30 Mar 1999, Ed Cogburn wrote: The point being, do NOT assume that the person trying to load the orignial Red Hat package even knows what a Makefile is. If he manages to understand how to convert an rpm to a tarball, he will surely understand how to use alien to make a .deb package, and will be smart enough to understand the process. Marek, I think George's point is Joe Blow doesn't *have* to understand using alien to convert a .rpm to a .deb, alien does everything for him. The problem starts when the newly created .deb still fails to work because of assumptions about the layout of the distro made by the creators of the .rpm. Ok, I agree. I feel I have to explain myself a little bit. Working for an ISP, I have contact with many people working on Winblows-equipped machines. Those people have accounts on our Linux machines and when faced with the necessity to actually read some documentation, they are completely shocked one HAS to learn something! Winblows created a generation of totally ignorant power users of PCs - M$ policy is to free people from thinking by creating software which does almost everything for the user - either automatically or by dictating all the steps required to achieve some goal. It may seem it is good - an average user doesn't have to master obscure techniques to manage his data and do his work, but what happens if the infallible Micro$oft software reveals another undocumented feature (a.k.a a bug :-)))? Our power user proud of his knowledge opens wide his eyes, stares at the Big Blue Screen(tm) with disbelief in his eyes and finally dials the M$ support number (where he will learn nothing new...). And the sad thing is that usually the problem is quite obvious, easy to fix or work around - solution is at hand, but Joe Blow hasn't been taught how to THINK when using a computer - he'd been given a piece of software that CLAIMS it doesn't require ANY knowledge to use it, that is supposed to work for ever and ever. Amen. Unfortunately, the software kicks back at our Joe and he knows nothing about how to win that game, he has NO resources (of some value) when he can read about the problem, even more - he thinks the software is so perfect he doesn't need to know ANYTHING about it - it will work, period... If he was told: Joe, the software will work in most cases, but should it fail you have the documentation, right there, use this or that command to read it, it's nothing hard, just a few tips - you will save time and money by fixing most of the problems on your own I'm sure he'd manage the situation... So, I think the way to go is NOT TO DO EVERYTHING FOR THE USER, but to GIVE ADVICE, EXPLAIN, HELP and MAKE THEM THINK a little bit about what's happening in their computer. Unix has never been and, I hope, it will never be an operating system that frees people from thinking... I've said this before and I'll say it again here: alien does *NOT* solve the problem of an absence of a 'standard' for Linux distros. Is such a standard possible at all? I mean, not on a paper - they already exist, after all, but is it possible that RH, Debian and other dist vendors will ever come to some agreement? It doesn't show on the surface, but there's a war raging under the cover - some want to provide GOOD products, but some just want to make money... Sad but true... marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Tue, 30 Mar 1999, Ed Cogburn wrote: Hmm... that's right, but it's only a matter of people talking to each other and agreeing upon one policy - the dists that don't follow the chosen standard, can rearrange their layout starting with the next release (yes, I know, it might be quite difficult, but worth the effort). There's no point in creating something new instead of using one of the few, very well tested and proven solutions. The closer RH gets to becoming the 'de facto' standard, the less likely they are to be inclined to talk to *anyone* about 'standards' for Linux distros. I fear the point at which RH drops That's a sad truth... its interest in LSB and other cooperative discussions about standards and simply says: If you want the standard Linux, you have to buy it from us. Power corrupts, and absolute power corrupts absolutely. And yes, if you haven't figured out by now, I *don't* trust RH. :-) Neither do I. I spent too much time making their dist a safe one to use on a public access server... marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sat, 27 Mar 1999, Christian Dysthe wrote: Hi again, guess what I need to know is how do you start programs at boot on a Debian system. I have tried to put my soundon* script from OSS in rc.boot and I get an error message when booting saying: cat uses obsolete /proc/pci interface It has nothing to do with the startup sequence. The 2.2.x (and 2.1.x) have introduced another interface to report about the PCI bus devices on your system. Kernels prior to 2.1.x used /proc/pci to publish this information in a textual form, while the =2.1.x kernels have /proc/bus/pci interface which exports that data in a binary form which is translated into human-readable data using the pciutils package. /proc/pci can be compiled into kernel for compatibility reasons, but the kernel can complain about some program using an obsolete interface, as it did in your case. It must be a way to load software/scripts in a simple way when booting. Or isn't it? Oh, there is. Just put an executable script in /etc/init.d. For your convenience, there's a skeleton file in /etc/init.d/skeleton which you can use as a template for a properly constructed startup file. marek -- -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia Comment: Requires PGP version 2.6 or later. mQCNAzao258AAAEEAM7hrSfj5QmbZMJ64b1COVrXNuraF95y8Djln0a37UBlLZQ7 4EJ9Die2V2kUSb4ndpCC5owSvR7KWBq6XYTVw7ne42PfzgIe/l+xG2e9pmztS1oZ Yhyow8aQ4Thlw286dvjuqWQ00M0s3XnWB24SpiQzsYZOwEfdlZ1EuNB7BOoNAAUR tCRNYXJlayBIYWJlcnNhY2sgPGdyZW5kZWxAdmlwLm5ldC5wbD6JAJUDBRA2qNuf nUS40HsE6g0BAfYuA/9NShgAKJ/iM5uSYmNXt6srSOIwUumqoVl0GVzXFHFPQaFB gqf2e2wNBIQH5DpGOYeyVW5GWsho+aM3lsPIMgCxKUb2sOuLzywl89GPnoAOc37B UQsbFdTH8cyQGoEjwHgqyu+7Omc5ptGXMjuYO0NN++tQsGRETcnwzSWviGExuA== =+3ah -END PGP PUBLIC KEY BLOCK-
Re: Where is /etc/rc.d/rc.local on Debian?
On 28 Mar 1999, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], Marek Habersack [EMAIL PROTECTED] wrote: 1. What RH package there is which has no Debian equivalent? 2. Why should Debian be RH-compatible? If someone switches to Debian from RH s/he should be prepared that some (re)adaptation will be necessary. The guys from the LSB (Linux Base Standard) are currently talking with Debian and RedHat to agree on one standard /etc/init.d structure. It will probably be abstracted and have symbolic names and dependencies. Eechh yet another standard?? Like it wasn't easier to chose one from the existing ones... marek -- -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia Comment: Requires PGP version 2.6 or later. mQCNAzao258AAAEEAM7hrSfj5QmbZMJ64b1COVrXNuraF95y8Djln0a37UBlLZQ7 4EJ9Die2V2kUSb4ndpCC5owSvR7KWBq6XYTVw7ne42PfzgIe/l+xG2e9pmztS1oZ Yhyow8aQ4Thlw286dvjuqWQ00M0s3XnWB24SpiQzsYZOwEfdlZ1EuNB7BOoNAAUR tCRNYXJlayBIYWJlcnNhY2sgPGdyZW5kZWxAdmlwLm5ldC5wbD6JAJUDBRA2qNuf nUS40HsE6g0BAfYuA/9NShgAKJ/iM5uSYmNXt6srSOIwUumqoVl0GVzXFHFPQaFB gqf2e2wNBIQH5DpGOYeyVW5GWsho+aM3lsPIMgCxKUb2sOuLzywl89GPnoAOc37B UQsbFdTH8cyQGoEjwHgqyu+7Omc5ptGXMjuYO0NN++tQsGRETcnwzSWviGExuA== =+3ah -END PGP PUBLIC KEY BLOCK-
Re: Where is /etc/rc.d/rc.local on Debian?
On Sat, 27 Mar 1999, Christian Dysthe wrote: textual form, while the =2.1.x kernels have /proc/bus/pci interface which exports that data in a binary form which is translated into human-readable data using the pciutils package. /proc/pci can be compiled into kernel for compatibility reasons, but the kernel can complain about some program using an obsolete interface, as it did in your case. marek Does this mean that the OSS driver (the commercial one) isn't ready for kernels 2.1.x and above, and that I should expect an updated driver that uses the new interface? I don't know about that driver, I don;t use it, so I can't comment on it being ready or not, but I'd suggest you use the ALSA sound modules which are really good, and already in the Debian distribution. But the message you mentioned is a harmless warning only meaning that your package X MAY be incompatible with the latest kernels one day, should the mentioned interface vanish. marek -- -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia Comment: Requires PGP version 2.6 or later. mQCNAzao258AAAEEAM7hrSfj5QmbZMJ64b1COVrXNuraF95y8Djln0a37UBlLZQ7 4EJ9Die2V2kUSb4ndpCC5owSvR7KWBq6XYTVw7ne42PfzgIe/l+xG2e9pmztS1oZ Yhyow8aQ4Thlw286dvjuqWQ00M0s3XnWB24SpiQzsYZOwEfdlZ1EuNB7BOoNAAUR tCRNYXJlayBIYWJlcnNhY2sgPGdyZW5kZWxAdmlwLm5ldC5wbD6JAJUDBRA2qNuf nUS40HsE6g0BAfYuA/9NShgAKJ/iM5uSYmNXt6srSOIwUumqoVl0GVzXFHFPQaFB gqf2e2wNBIQH5DpGOYeyVW5GWsho+aM3lsPIMgCxKUb2sOuLzywl89GPnoAOc37B UQsbFdTH8cyQGoEjwHgqyu+7Omc5ptGXMjuYO0NN++tQsGRETcnwzSWviGExuA== =+3ah -END PGP PUBLIC KEY BLOCK-
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Pollywog wrote: On 28-Mar-99 Christian Dysthe wrote: Well, I did put the OSS startup script in rc.boot, and the drivers load and work fine. The only problem is the message I get about obsolete pci device which, as I was informed here, has nothing to do with the way the driver is loaded. Odd. I don't get that obsolete PCI message. Me neither, at least when using cat. But MC does produce that message in kernel logs. marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sat, 27 Mar 1999, George Bonser wrote: On Sun, 28 Mar 1999, Marek Habersack wrote: 1. What RH package there is which has no Debian equivalent? HP FireHunter for example. You got me there. So it means nobody packages it for Debian? Well, so the solution is to make the whole Debian distribution compatible with RH just for the sake of one package? Isn't it better to repackage it for Debian? No that I'm willing to do it :)) but someone who uses it, could, am I right? 2. Why should Debian be RH-compatible? If someone switches to Debian from RH s/he should be prepared that some (re)adaptation will be necessary. Because there are several commercial software packages distributed in RPM format for the Red Hat layout that are NOT available in tarball format. Hmm... It's not very hard to take a source RPM, which MUST have a tarball inside, take the tarball out and package it for Debian... And if what you're saying is that those packages are commercial apps, then they're not in the Debian spirit anyway marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sat, 27 Mar 1999, George Bonser wrote: On 28 Mar 1999, Miquel van Smoorenburg wrote: The guys from the LSB (Linux Base Standard) are currently talking with Debian and RedHat to agree on one standard /etc/init.d structure. It will probably be abstracted and have symbolic names and dependencies. HORSE PUCKY! There are two standards, SysV and BSD ... PICK ONE! I second that 100%!! And I don't care WHICH one will be used, but for God's sake, don't reinvent the wheel! marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Hamish Moffatt wrote: On Sun, Mar 28, 1999 at 02:00:16AM +0200, Marek Habersack wrote: I know it is for one-time boottime initialization of some packages. But in the absense of rc.local it can be used, as a poor-man's substitute. OTOH, the two startup file layout standards haven't been designed to be intermixed, so I guess that this discussion is purely theoretical and inpractical... There is no absence of rc.local -- you just have to make it yourself. Just do the following: cd /etc/init.d vi local chmod +x local update-rc.d local defaults Hamish
Re: Where is /etc/rc.d/rc.local on Debian?
On 28 Mar 1999, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], Marek Habersack [EMAIL PROTECTED] wrote: On 28 Mar 1999, Miquel van Smoorenburg wrote: The guys from the LSB (Linux Base Standard) are currently talking with Debian and RedHat to agree on one standard /etc/init.d structure. It will probably be abstracted and have symbolic names and dependencies. Eechh yet another standard?? Like it wasn't easier to chose one from the existing ones... As you know, RedHat, Debian, Suse etc have very different bootup procedures. We don't want ISVs to bother with that. So we need a system that works across distributions. Hmm... that's right, but it's only a matter of people talking to each other and agreeing upon one policy - the dists that don't follow the chosen standard, can rearrange their layout starting with the next release (yes, I know, it might be quite difficult, but worth the effort). There's no point in creating something new instead of using one of the few, very well tested and proven solutions. On debian-devel there has been talk about a better setup with dpkg-like dependancies. This is a good thing. You don't have to bother with at which priority to place a new service. You can just say this service must be started after networking and name services are available. That's certainly a good thing. The LSB people are seriously looking at a system already created by fellow Debian developers which does all this and more. Normally I don't like changing something that's working either. I do not really like things like file-rc. But this is actually something that is not an alternative but a superiour solution. I agree. I used to think that what RH uses to setup the daemon startup order is good, but file-rc is much better. Well, it's one of those changes that make your life easier IMO. marek
Re: Where is /etc/rc.d/rc.local on Debian?
On 28 Mar 1999, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], George Bonser [EMAIL PROTECTED] wrote: On 28 Mar 1999, Miquel van Smoorenburg wrote: The guys from the LSB (Linux Base Standard) are currently talking with Debian and RedHat to agree on one standard /etc/init.d structure. It will probably be abstracted and have symbolic names and dependencies. HORSE PUCKY! There are two standards, SysV and BSD ... PICK ONE! Okay, I am vendor X and want to put my boot script somewhere. a) where do I put it b) at which priority c) in which runlevel Oh that's different between Redhat Debian Suse Slackware etc and I have to create packages for all of them you say? Oh well I guess I'll just create an RPM for RedHat then Nah... I'll ask on debian-devel and someone will create an equivalent to the RH's checkconfig (AFAIR) command that will nicely allow one to use the same call for all the three distributions. marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Marc Haber wrote: On 28 Mar 1999 11:02:24 +0200, you wrote: Besides, /etc/rc.boot has been deprecated and will disappear. How am I supposed to early load daemons (like scsidev which should be loaded before any disks are mounted)? Well, you must have at least / mounted to load any module, or boot from the network. And if you have / mounted, then put your script in /etc/rcS.d - there's a README in that directory that explains what it's for. marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Branden Robinson wrote: On Sun, Mar 28, 1999 at 11:07:46AM +0200, Miquel van Smoorenburg wrote: On debian-devel there has been talk about a better setup with dpkg-like dependancies. This is a good thing. You don't have to bother with at which priority to place a new service. You can just say this service must be started after networking and name services are available. Oh, this would really rock if it would work for xdm; if I could say only start xdm once getty has grabbed all the virtual consoles listed for this runlevel in inittab. Hmm you can do it even now - with the rc-file package.
Re: Where is /etc/rc.d/rc.local on Debian?
On 28 Mar 1999, Martin Bialasinski wrote: GB == George Bonser [EMAIL PROTECTED] writes: GB Because there are several commercial software packages distributed GB in RPM format for the Red Hat layout that are NOT available in GB tarball format. You can always convert a rpm to a tarball. You don't have to. Just get the src rpm marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Christian Dysthe wrote: Seems to me adding stuff to rcS.d would jeopardize using single mode booting as a tool when somethiing in your default runlevel won't run right? Still, it might be the replacement of rc.boot. After my initial posting in this thread I must say that Debian, and maybe Linux in general, has a complicated, not very user friendly, way of handling loading of drivers and programs at boot. Both DOS/Windows and OS/2 handles this more elegantly. Hmm DOS/Windows and OS/2 are PC operating systems, Linux is Unix and administration doesn't have to be user friendly - for your home needs, your dist vendor does for you all you need, for the open community needs, it takes a system administrator to manage the machine and such a person should RTFM - ALL OF THEM... And, IMO, the way of loading programs and devices is quite elegant and simple :- I am more confused than ever :) And I'm confused with the odd mixture of CONFIG.SYS, AUTOEXEC.BAT, WINSTART.BAT, registry, WIN.INI, SYSTEM.INI, somethingelse.ini of M$ Windows... marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Christian Dysthe wrote: This is the sad truth. If this simple task shall continue to be complicated, vendors will create packages for their distribution of fancy. My problen is that this is already the case with some vendors. I never thought when I switched to Linux a couple of months ago I would have problems like this oneI thought I would struggle with modems and incomaptible hardware, but no, I have problems loading stuff at boot.. I still don't see where do you see the problem? Wanna start something at boot? Put the startup script in /etc/init.d What can be simpler? You even have a template which requires a three-line modification... marek
Re: Where is /etc/rc.d/rc.local on Debian?
On 28 Mar 1999, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], Marek Habersack [EMAIL PROTECTED] wrote: I know it is for one-time boottime initialization of some packages. But in the absense of rc.local it can be used, as a poor-man's substitute. OTOH, the two startup file layout standards haven't been designed to be intermixed, so I guess that this discussion is purely theoretical and inpractical... No. Go back and _read_ the archives. /etc/rc.boot runs very early in the boot process. No daemons (except maybe portmap) are running yet. No named, no syslogd, no apache etc. Historically, /etc/rc.local runs as the _last_ thing in the boot process. The system has been initialized fully before rc.local runs. There is a key difference. Ok, I re-read the archives, my apologies... marek
Re: PHP Apache 1.3.5
On Sun, 28 Mar 1999, Remco van de Meent wrote: Marek Habersack wrote: Does anyone know where can I find binary debs for PHP compiled to work with Apache 1.3.5? I don't think they're available. However, Apache 1.3.6 is in the current distribution, and I think (but I'm not sure) that the php3 packages will be Yes, I've got that already... replaced by apache-1.3.6-compatible ones soon. Hmm... how soon? I've got a few other modules compiled for 1.3.6 and PHP3 are the only ones that don't work... and users are pushing me :))). As a side note, the PHP3 modules haven't been changed since Apache 1.3.3... and that was almost three weeks ago... marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, George Bonser wrote: On 28 Mar 1999, Martin Bialasinski wrote: You can always convert a rpm to a tarball. Ciao, Martin Yeah and then edit everything to put stuff in different places (and hope something somewhere dosn't have a location hardcoded.). In other words, this works if you really know what you are doing and don't mind spending the time to muck with it. Come on!!! Go back and re-read your statement... What's packaging all about? About changing the binary installation layout of some package to fit particular dist's requiremets or some standard of other sorts. And where do you imagine you get all those spiffy packages in Debian from? It's from hundreds of people EDITING EVERYTHING so that you can just type dpkg -i package.deb and enjoy the way it works... marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Brian Servis wrote: You can always convert a rpm to a tarball. You don't have to. Just get the src rpm Read what George said, that doesn't work for things like Applixware or other commercial programs that DO NOT HAVE SRC RPM. Those also tend to have hardcoded directory structures built into the binaries that are not configurable and were only designed to be run an a Red Hat system. Hmm... did you read the Debian Policy manual? marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Brian Servis wrote: not configurable and were only designed to be run an a Red Hat system. Hmm... did you read the Debian Policy manual? I'm confused, what does the policy manual have to do with compatibility between Red Hat and Debian init structure and converting an .rpm to a .deb or .tgz? Besides the policy manual is not up to date on the /etc/rcS.d and /etc/rc.boot issue. Read the section 2.1.1 of the manual and relate that to the Applixware package... It has nothing to do with the package compatibility, but puts it in plain vanilla that Applixware shall not be a part of Debian, so what George said can't be an argument in this discussion. Maybe I'm wrong... marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, George Bonser wrote: On Sun, 28 Mar 1999, Marek Habersack wrote: You don't have to. Just get the src rpm marek You are NEVER going to find a SRPM of HP FireHunter, or any other commercial software pre-packaged for Red Hat. Well, such software won't make it into Debian then... I guess... marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Brian Servis wrote: You are NEVER going to find a SRPM of HP FireHunter, or any other commercial software pre-packaged for Red Hat. Well, such software won't make it into Debian then... I guess... Correct. Maybe in non-free if the company will let Debian redistribute it but that is pretty rare. Yes, it is... Here we hit another problem: how to make Debian more attractive for commercial vendors without sacrificing it's pure GNU nature? But if it is only available in .rpm format and designed to work on a Red Hat system and has the Red Hat init structure, or file system, hard coded into it, then everyone who is running a distro that is not Red Hat is screwed. The alien package tries to do its best to convert .rpm's to .deb's for file install locations. But if the program has hardcoded file structure in the binary or scripts then the effort of converting the .rpm to a .deb is useless because the program will not run unless it finds the files in the places that it expects it. That's right. One, very inelegant, solution would be to add an init script to the deb package that would create a required set of symlinks to make the debian system compatible with the RH one. But first - it pollutes the file system, second - well, it makes Debian lose in some sense... Other solution I can think of, more wasteful in terms of space, but more elegant, would be to create a set of wrapper scripts or programs that'd allow to run the application in question in a chrooted evironment simulating the RH file system layout. Requires a bit of effort, but IMO it could work... I agree that there there has to be a standard used by ALL Linux distros so that commercial vendors do not have to worry about which distro to be compatible with. Agreed, but there should be NO new standard... marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Christian Dysthe wrote: dist vendor does for you all you need, for the open community needs, it takes a system administrator to manage the machine and such a person should RTFM - ALL OF THEM... And, IMO, the way of loading programs and devices is quite elegant and simple :- The problem is when software you want only is packaged for one or two distributions. At least in Win Dos and OS/2 progrmas written for the platform Hmm... there aren't THAT many such packages, and those existing are mostly commercial packages that usually have their free counterpart. So, you HAVE A CHOICE will install on all machines running the OS. In Linux you come acrosss Hmm... frankly, I haven't met software that wouldn't install on any machine running any Linux distribution. Sometime one has to read few docs, make some changes - but it takes a moment and you do it only once... software with documentation tell you it will run on for instance Linux with glibc. What it should also say is that you have to wait for your distribution to package the software so that it will *install* correctly. Hmm well, telling that to the user is the vendor's responsibilty, not the distribution's (IF the software isn't a part of the dist, of course). One thing is that it will run, another is: Will it install? What makes it even worse is that the programs I have wanted to run install fine, it is just having them load at boot that is the problem. You shoudn't need a system admin (unless a software based system manager for Linux was developed) to accomplish this. Hmm... have you taken a look at linuxconf? It might be what you need. I didn't use it personally, so I cannot comment on it, but the word is it does the job for RH and Debian as well. If we want Linux to be wide spread simple/basic tasks like these should be easy to do for the a little above average computer user, or at least standarized for Linux as a whole. But they are REALLY easy! It takes just one night for an average user to READ the documentation... We surely don't want people to stop thinkink, do we? I am more confused than ever :) And I'm confused with the odd mixture of CONFIG.SYS, AUTOEXEC.BAT, WINSTART.BAT, registry, WIN.INI, SYSTEM.INI, somethingelse.ini of M$ Windows... I am also at times, but at least it is manageable without being a system admin ;) yeah... until it suddenly loses all your installed fonts, or hangs when you start the Winblows Explorer and you scratch your head I didn't change anything here within last two weeks, yesternight it worked... Why doesn;t it work anymore?? Ahh, the hell!, I'll reinstall it... and believe me, I once installed Win95 on one machine 15 times in row... until it worked... :))) I'd rather spare one night to read all the available docs dealing with Debian startup than waste one day watching the splash screens during winblows install saying how much fun computing will be with the latest Micro$oft Crapware... : marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Christian Dysthe wrote: The problem is that there has been a lot of talk about new standards, putting it in rc.boot, creating a jungle of sym links etc. Take a look at this thread! :) Err... : yeah, :-))) marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, George Bonser wrote: you imagine you get all those spiffy packages in Debian from? It's from hundreds of people EDITING EVERYTHING so that you can just type dpkg -i package.deb and enjoy the way it works... marek No, Marek, you reread my original. Joe Blow gets some package designed for Red Hat. How is he going to install that on his Debian system. He learns he can convert it to a tarball ... whats that? Ok, so he does it. It still won't install. Hmmm, looks like I have to call a $200/hr Unix consultant to see IF I can get this stuff installed on my system. The point being, do NOT assume that the person trying to load the orignial Red Hat package even knows what a Makefile is. If he manages to understand how to convert an rpm to a tarball, he will surely understand how to use alien to make a .deb package, and will be smart enough to understand the process. marek
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, George Bonser wrote: You got me there. So it means nobody packages it for Debian? Well, so the solution is to make the whole Debian distribution compatible with RH just for the sake of one package? Isn't it better to repackage it for Debian? No that I'm willing to do it :)) but someone who uses it, could, am I right? No, I think a better idea is to simply make ALL distributions compatable. Agreed. Create a Linux standard init structure and USE IT. Create a Linux standard That's a nono, imho! There ARE already good standards that deal with it - just make all the people chose one of them... filesystem layout and USE IT. Heck, buy Red Hat and file bugs against their distro using their own bug reporting system for stuff that does not meet the standard. Get Linus on board. Say that you have to meet the standard to call the product Linux. We have GOT to avoid the Unix problem. Agreed again.
Re: Where is /etc/rc.d/rc.local on Debian?
On Sun, 28 Mar 1999, Branden Robinson wrote: On Sun, Mar 28, 1999 at 09:13:03PM +0200, Marek Habersack wrote: On Sun, 28 Mar 1999, Branden Robinson wrote: Oh, this would really rock if it would work for xdm; if I could say only start xdm once getty has grabbed all the virtual consoles listed for this runlevel in inittab. Hmm you can do it even now - with the rc-file package. Bt. I'm not going to make people install file-rc just to fix this (wishlist) bug. If I can't do it nicely with the default Debian init system, I'm not going to do it. Well, I hope that one day file-rc will be the default package because it's really good. I use it without any problems, it's really great... marek
PHP Apache 1.3.5
Hi, Does anyone know where can I find binary debs for PHP compiled to work with Apache 1.3.5? thanks in advance marek -- -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia Comment: Requires PGP version 2.6 or later. mQCNAzao258AAAEEAM7hrSfj5QmbZMJ64b1COVrXNuraF95y8Djln0a37UBlLZQ7 4EJ9Die2V2kUSb4ndpCC5owSvR7KWBq6XYTVw7ne42PfzgIe/l+xG2e9pmztS1oZ Yhyow8aQ4Thlw286dvjuqWQ00M0s3XnWB24SpiQzsYZOwEfdlZ1EuNB7BOoNAAUR tCRNYXJlayBIYWJlcnNhY2sgPGdyZW5kZWxAdmlwLm5ldC5wbD6JAJUDBRA2qNuf nUS40HsE6g0BAfYuA/9NShgAKJ/iM5uSYmNXt6srSOIwUumqoVl0GVzXFHFPQaFB gqf2e2wNBIQH5DpGOYeyVW5GWsho+aM3lsPIMgCxKUb2sOuLzywl89GPnoAOc37B UQsbFdTH8cyQGoEjwHgqyu+7Omc5ptGXMjuYO0NN++tQsGRETcnwzSWviGExuA== =+3ah -END PGP PUBLIC KEY BLOCK-
Re: Where is /etc/rc.d/rc.local on Debian?
On Sat, 27 Mar 1999, George Bonser wrote: I am a newbie and do not undestand the init files in Debian yet. I have tried to read up on it, but I am still confused. Can anyone help me out, please? Debian uses standard System V init files. There is no such thing as rc.d or rc.local in SysV, they come from BSD unix. You can fix the problem partially by creating a /etc/rc.d directory and then under that symlinking /etc/rc1.d to /etc/rc.d/rc1/d and so on for rc1.d through rc6.d as well as init.d. Then you might create a file called local in /etc/init.d and install it with update-rc.d with a 99 so it gets run last. Then symlink /etc/init.d/local to /etc/rc.d/rc.local. Hmm... isn't that a bit overkill? Why don't you just put stuff in /etc/rc.boot or do cd /etc;mkdir rc.d;ln -sf rc.boot rc.d/rc.local??? marek -- -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia Comment: Requires PGP version 2.6 or later. mQCNAzao258AAAEEAM7hrSfj5QmbZMJ64b1COVrXNuraF95y8Djln0a37UBlLZQ7 4EJ9Die2V2kUSb4ndpCC5owSvR7KWBq6XYTVw7ne42PfzgIe/l+xG2e9pmztS1oZ Yhyow8aQ4Thlw286dvjuqWQ00M0s3XnWB24SpiQzsYZOwEfdlZ1EuNB7BOoNAAUR tCRNYXJlayBIYWJlcnNhY2sgPGdyZW5kZWxAdmlwLm5ldC5wbD6JAJUDBRA2qNuf nUS40HsE6g0BAfYuA/9NShgAKJ/iM5uSYmNXt6srSOIwUumqoVl0GVzXFHFPQaFB gqf2e2wNBIQH5DpGOYeyVW5GWsho+aM3lsPIMgCxKUb2sOuLzywl89GPnoAOc37B UQsbFdTH8cyQGoEjwHgqyu+7Omc5ptGXMjuYO0NN++tQsGRETcnwzSWviGExuA== =+3ah -END PGP PUBLIC KEY BLOCK-
Re: Where is /etc/rc.d/rc.local on Debian?
On Sat, 27 Mar 1999, George Bonser wrote: On Sat, 27 Mar 1999, Marek Habersack wrote: On Sat, 27 Mar 1999, George Bonser wrote: Hmm... isn't that a bit overkill? Why don't you just put stuff in /etc/rc.boot or do cd /etc;mkdir rc.d;ln -sf rc.boot rc.d/rc.local??? Not if you just want stuff designed for Red Hat to simply install. You can do as you say for a single package, maybe, but it is probably better to simulate the RH non-standard environment if you will be installing more than one package designed for Red Hat (the hat is red from blood caused by one pulling all of one's hair out trying to make sense of their goofy layout). Just two questions: 1. What RH package there is which has no Debian equivalent? 2. Why should Debian be RH-compatible? If someone switches to Debian from RH s/he should be prepared that some (re)adaptation will be necessary. marek -- -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia Comment: Requires PGP version 2.6 or later. mQCNAzao258AAAEEAM7hrSfj5QmbZMJ64b1COVrXNuraF95y8Djln0a37UBlLZQ7 4EJ9Die2V2kUSb4ndpCC5owSvR7KWBq6XYTVw7ne42PfzgIe/l+xG2e9pmztS1oZ Yhyow8aQ4Thlw286dvjuqWQ00M0s3XnWB24SpiQzsYZOwEfdlZ1EuNB7BOoNAAUR tCRNYXJlayBIYWJlcnNhY2sgPGdyZW5kZWxAdmlwLm5ldC5wbD6JAJUDBRA2qNuf nUS40HsE6g0BAfYuA/9NShgAKJ/iM5uSYmNXt6srSOIwUumqoVl0GVzXFHFPQaFB gqf2e2wNBIQH5DpGOYeyVW5GWsho+aM3lsPIMgCxKUb2sOuLzywl89GPnoAOc37B UQsbFdTH8cyQGoEjwHgqyu+7Omc5ptGXMjuYO0NN++tQsGRETcnwzSWviGExuA== =+3ah -END PGP PUBLIC KEY BLOCK-
Re: Where is /etc/rc.d/rc.local on Debian?
On 28 Mar 1999, Miquel van Smoorenburg wrote: In article [EMAIL PROTECTED], Marek Habersack [EMAIL PROTECTED] wrote: Hmm... isn't that a bit overkill? Why don't you just put stuff in /etc/rc.boot or do cd /etc;mkdir rc.d;ln -sf rc.boot rc.d/rc.local??? NO /etc/rc.boot and rc.local are totally different things. If you do not know what you are doing DO NOT use /etc/rc.boot Read about this in the archives. It has come up at least 60 times before. I know it is for one-time boottime initialization of some packages. But in the absense of rc.local it can be used, as a poor-man's substitute. OTOH, the two startup file layout standards haven't been designed to be intermixed, so I guess that this discussion is purely theoretical and inpractical... marek -- -BEGIN PGP PUBLIC KEY BLOCK- Version: 2.6.3ia Comment: Requires PGP version 2.6 or later. mQCNAzao258AAAEEAM7hrSfj5QmbZMJ64b1COVrXNuraF95y8Djln0a37UBlLZQ7 4EJ9Die2V2kUSb4ndpCC5owSvR7KWBq6XYTVw7ne42PfzgIe/l+xG2e9pmztS1oZ Yhyow8aQ4Thlw286dvjuqWQ00M0s3XnWB24SpiQzsYZOwEfdlZ1EuNB7BOoNAAUR tCRNYXJlayBIYWJlcnNhY2sgPGdyZW5kZWxAdmlwLm5ldC5wbD6JAJUDBRA2qNuf nUS40HsE6g0BAfYuA/9NShgAKJ/iM5uSYmNXt6srSOIwUumqoVl0GVzXFHFPQaFB gqf2e2wNBIQH5DpGOYeyVW5GWsho+aM3lsPIMgCxKUb2sOuLzywl89GPnoAOc37B UQsbFdTH8cyQGoEjwHgqyu+7Omc5ptGXMjuYO0NN++tQsGRETcnwzSWviGExuA== =+3ah -END PGP PUBLIC KEY BLOCK-
