Re: /sbin vs /bin
to...@tuxteam.de wrote:
> On Sat, Jul 30, 2022 at 02:07:58PM -0400, Greg Wooledge wrote:
> > On Sat, Jul 30, 2022 at 02:02:21PM -0400, Timothy M Butterworth wrote:
> > > Logging in as root has become taboo. Sudo is the prefered mechanism for
> > > running administrator functions. I have root set to nologin with a null
> > > password to force sudo usage.
> >
> > This makes entering single-user mode ("rescue mode") impossible.
>
> Agreed. There are ways around that, but logging in as root while
> physically present is a quite honourable thing to do.
>
> Some swing this way, others the other way. Use the tool which suits
> you. Know its limitations.
>
> FWIW, not long ago sudo had a vulnerability. It is just much more
> complex, and complexity is an enemy of security (I say that as a
> fan of sudo and as a regular user).
The OpenBSD folk created "doas", which is packaged in Bullseye.
Description: minimal replacement for sudo
OpenDoas: a portable version of OpenBSD's doas command
doas is a minimal replacement for the venerable sudo. It was
initially written by Ted Unangst of the OpenBSD project to provide 95% of the
features of sudo with a fraction of the codebase.
I haven't used it, but I suspect it is excellent for
single-sysadmin machines.
-dsr-
Re: /sbin vs /bin
On Sat 30 Jul 2022 at 20:21:00 (+0200), to...@tuxteam.de wrote:
> On Sat, Jul 30, 2022 at 02:07:58PM -0400, Greg Wooledge wrote:
> > On Sat, Jul 30, 2022 at 02:02:21PM -0400, Timothy M Butterworth wrote:
> > > Logging in as root has become taboo. Sudo is the prefered mechanism for
> > > running administrator functions. I have root set to nologin with a null
> > > password to force sudo usage.
> >
> > This makes entering single-user mode ("rescue mode") impossible.
>
> Agreed. There are ways around that, but logging in as root while
> physically present is a quite honourable thing to do.
>
> Some swing this way, others the other way. Use the tool which suits
> you. Know its limitations.
>
> FWIW, not long ago sudo had a vulnerability. It is just much more
> complex, and complexity is an enemy of security (I say that as a
> fan of sudo and as a regular user).
> > > I would love to see Debian Bookworm disable
> > > root login by default.
Why? Any competent sysadmin can do that themselves easily enough.
The choices offered by the d-i are quite sufficient for a home user.
Cheers,
David.
Re: /sbin vs /bin
On Sat, Jul 30, 2022 at 02:07:58PM -0400, Greg Wooledge wrote:
> On Sat, Jul 30, 2022 at 02:02:21PM -0400, Timothy M Butterworth wrote:
> > Logging in as root has become taboo. Sudo is the prefered mechanism for
> > running administrator functions. I have root set to nologin with a null
> > password to force sudo usage.
>
> This makes entering single-user mode ("rescue mode") impossible.
Agreed. There are ways around that, but logging in as root while
physically present is a quite honourable thing to do.
Some swing this way, others the other way. Use the tool which suits
you. Know its limitations.
FWIW, not long ago sudo had a vulnerability. It is just much more
complex, and complexity is an enemy of security (I say that as a
fan of sudo and as a regular user).
Cheers
--
"all generalisations suck" tomás
signature.asc
Description: PGP signature
Re: /sbin vs /bin
On Sat, Jul 30, 2022 at 02:02:21PM -0400, Timothy M Butterworth wrote:
> Logging in as root has become taboo. Sudo is the prefered mechanism for
> running administrator functions. I have root set to nologin with a null
> password to force sudo usage.
This makes entering single-user mode ("rescue mode") impossible.
> One of the major issues with su root is that
> in a work environment with more than one administrator you would have to
> share the root password. Sharing one account provided no accountability as
> to who actually made changes. I would love to see Debian Bookworm disable
> root login by default. Root is a security vulnerability because the user
> name is known so it is easy to launch a brute force attack against the
> server.
If it's about "attacking a server", the default sshd configuration which
disallows root logins is already sufficient. There's no reason to stop
people from using a root password locally, to stop single-user mode from
working, etc.
(Of course, if that's what you want on *your* systems, you're free to do
that. I just don't think it's necessary to impose it on everyone else
by fiat.)
Re: /sbin vs /bin
On Fri, Jul 29, 2022 at 7:08 AM Greg Wooledge wrote: > On Thu, Jul 28, 2022 at 11:39:01PM -0500, Igor Korot wrote: > > Open the Terminal > > Become root by running su > > Try to run ldconfig -> "Command not found" > > Try to run /sbin/ldconfig -> execution successful > > https://wiki.debian.org/NewInBuster#Changes > > Changes > > The su command in buster is provided by the util-linux source package, > instead of the shadow source package, and no longer alters the PATH > variable by default. This means that after doing su, your PATH may > not contain directories like /sbin, and many system administration > commands will fail. There are several workarounds: > > * Use su - instead; this launches a login shell, which forces PATH > to be changed, but also changes everything else including the > working directory. > > * Use sudo instead. sudo still runs commands with an altered > PATH variable. > > o To get a regular root shell with the correct PATH, you may > use sudo -s. > > o To get a login shell as root (equivalent to su -), you may > use sudo -i. > > * Put ALWAYS_SET_PATH yes in /etc/default/su (create it) to get > an approximation of the old behavior. This is documented in su(1). > > * Put the system administration directories (/sbin, /usr/sbin, > /usr/local/sbin) in your regular account's PATH (see > EnvironmentVariables for help with this). > > Logging in as root has become taboo. Sudo is the prefered mechanism for running administrator functions. I have root set to nologin with a null password to force sudo usage. One of the major issues with su root is that in a work environment with more than one administrator you would have to share the root password. Sharing one account provided no accountability as to who actually made changes. I would love to see Debian Bookworm disable root login by default. Root is a security vulnerability because the user name is known so it is easy to launch a brute force attack against the server. -- ⢀⣴⠾⠻⢶⣦⠀ ⣾⠁⢠⠒⠀⣿⡁ Debian - The universal operating system ⢿⡄⠘⠷⠚⠋⠀ https://www.debian.org/ ⠈⠳⣄⠀⠀
Re: /sbin vs /bin
On Thu, Jul 28, 2022 at 11:39:01PM -0500, Igor Korot wrote: > Open the Terminal > Become root by running su > Try to run ldconfig -> "Command not found" > Try to run /sbin/ldconfig -> execution successful https://wiki.debian.org/NewInBuster#Changes Changes The su command in buster is provided by the util-linux source package, instead of the shadow source package, and no longer alters the PATH variable by default. This means that after doing su, your PATH may not contain directories like /sbin, and many system administration commands will fail. There are several workarounds: * Use su - instead; this launches a login shell, which forces PATH to be changed, but also changes everything else including the working directory. * Use sudo instead. sudo still runs commands with an altered PATH variable. o To get a regular root shell with the correct PATH, you may use sudo -s. o To get a login shell as root (equivalent to su -), you may use sudo -i. * Put ALWAYS_SET_PATH yes in /etc/default/su (create it) to get an approximation of the old behavior. This is documented in su(1). * Put the system administration directories (/sbin, /usr/sbin, /usr/local/sbin) in your regular account's PATH (see EnvironmentVariables for help with this).
Re: /sbin vs /bin
On Thu, Jul 28, 2022 at 11:39:01PM -0500, Igor Korot wrote: > Hi, David, > > On Thu, Jul 28, 2022 at 11:10 PM David Wright > wrote: > > > > On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote: > > > According to > > > https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386, > > > > > > ld config is located inside /sbin and it is installed through the > > > libc-bin. > > > > > > Trying to run ldconfig gives "No such file or directory" > > > Running "apt install libc-bin" says "Its installed and already a latest > > > version" > > > Only running "/sbin/ldconfig" makes it run. > > > > > > Is "/sbin" not in the default PATH variable? > > > > For an ordinary user: no. > > > > For root: yes. > > Wrong. ;-) > Boot into an OS and login as a regular user. > Open the Terminal > Become root by running su Ah, su. Don't use su unless you know very well what you are doing. Cheers -- t signature.asc Description: PGP signature
Re: /sbin vs /bin
On Thu 28 Jul 2022 at 23:39:01 (-0500), Igor Korot wrote: > On Thu, Jul 28, 2022 at 11:10 PM David Wright > wrote: > > On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote: > > > According to > > > https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386, > > > > > > ld config is located inside /sbin and it is installed through the > > > libc-bin. > > > > > > Trying to run ldconfig gives "No such file or directory" > > > Running "apt install libc-bin" says "Its installed and already a latest > > > version" > > > Only running "/sbin/ldconfig" makes it run. > > > > > > Is "/sbin" not in the default PATH variable? > > > > For an ordinary user: no. > > > > For root: yes. > > Wrong. ;-) > Boot into an OS and login as a regular user. > Open the Terminal > Become root by running su You'd better get up to date on the change made to the behaviour of su. If you run plain "su", you don't get root's default PATH variable, but whatever it was before. > Try to run ldconfig -> "Command not found" > Try to run /sbin/ldconfig -> execution successful Cheers, David.
Re: /sbin vs /bin
Hi, David, On Thu, Jul 28, 2022 at 11:10 PM David Wright wrote: > > On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote: > > According to > > https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386, > > > > ld config is located inside /sbin and it is installed through the libc-bin. > > > > Trying to run ldconfig gives "No such file or directory" > > Running "apt install libc-bin" says "Its installed and already a latest > > version" > > Only running "/sbin/ldconfig" makes it run. > > > > Is "/sbin" not in the default PATH variable? > > For an ordinary user: no. > > For root: yes. Wrong. ;-) Boot into an OS and login as a regular user. Open the Terminal Become root by running su Try to run ldconfig -> "Command not found" Try to run /sbin/ldconfig -> execution successful Thank you. > > Cheers, > David. >
Re: /sbin vs /bin
On Thu, Jul 28, 2022 at 11:10:07PM -0500, David Wright wrote: > On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote: > > According to > > https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386, > > > > ld config is located inside /sbin and it is installed through the libc-bin. > > > > Trying to run ldconfig gives "No such file or directory" > > Running "apt install libc-bin" says "Its installed and already a latest > > version" > > Only running "/sbin/ldconfig" makes it run. > > > > Is "/sbin" not in the default PATH variable? > > For an ordinary user: no. > > For root: yes. To complement this: if you do "sudo ldconfig" everything should work. If you log in as root and do ldconfig, everything should work, too. Note that you shouldn't be able to run ldconfig as non-root (it does change files only root should be able to change). So even if you try /sbin/ldconfig as a regular user (is it this what you are trying to do?), it is going to fail at a latter stage. Cheers -- t signature.asc Description: PGP signature
Re: /sbin vs /bin
On Thu 28 Jul 2022 at 22:37:39 (-0500), Igor Korot wrote: > According to > https://packages.debian.org/cgi-bin/search_contents.pl?word=ldconfig&searchmode=searchfiles&case=insensitive&version=stable&arch=i386, > > ld config is located inside /sbin and it is installed through the libc-bin. > > Trying to run ldconfig gives "No such file or directory" > Running "apt install libc-bin" says "Its installed and already a latest > version" > Only running "/sbin/ldconfig" makes it run. > > Is "/sbin" not in the default PATH variable? For an ordinary user: no. For root: yes. Cheers, David.
Re: sbin
On Thu, Jan 5, 2012 at 7:06 PM, Joel Rees wrote: > On Fri, Jan 6, 2012 at 3:42 AM, Tom H wrote: >> On Sun, Jan 1, 2012 at 11:58 AM, Camaleón wrote: >>> On Mon, 02 Jan 2012 00:42:10 +0800, lina wrote: >>> Is it safe to add /sbin into PATH? >>> >>> To you user env? If it's not an exposed system, I'd say yes. >> >> It's even OK on an "exposed" system. Having "(/usr)/sbin" in PATH for >> everyone is the default for RHEL, Fedora, and Ubuntu and, anyway, the >> executables in "(/usr)/sbin" are all "x" for "other". > > Somebody over there thinks that they should all be combined. Not sure > why, but the fact that the current separation is historically derived > from circumstance, not design, seems to figure large in the arguments. Yes, in the next version of Fedora, 16, "/bin/*", "/sbin/*", and "/lib/*" are being moved into "/usr/bin/", "/usr/sbin/", and "/usr/lib/". That's not quite the same thing. There's been talk of following up in a future version with a move of "/usr/sbin/*" into "/usr/bin/" but, AFAIK, the decision to implement this second unification hasn't been taken yet. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=szhmsmp+eat3hmwhrqppex+uus-5fd816assfmtmrt...@mail.gmail.com
Re: sbin
On Mon, Jan 2, 2012 at 1:52 AM, lina wrote: > On Monday 02,January,2012 12:50 AM, Joao Ferreira Gmail wrote: >> >> On Mon, 2012-01-02 at 00:42 +0800, lina wrote: >>> >>> Hi, >>> >>> Is it safe to add /sbin into PATH? >> >> there should be no problem, but a regular (non-root) user will not be >> able to do much with it because most of those executables will at some >> point require root privilege (at least that is my guess) >> >>> Why the default path not include /sbin, >> >> On my system (Debian wheezy) I have it on root's PATH but not on regular >> user's PATH: >> >> root@wheejy:~# echo $PATH >> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin >> >> jmf@wheejy:~$ echo $PATH >> /home/jmf/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games >> >> >> tipically those commands are not used (not supposed to be used) by >> regular users. >> >> But I guess it won't hurt to add it to the PATH > > Thanks, I just checked, it's included in root PATH, not in user path. > They really think so much to build a system. There those who encourage using full path for anything you call as user. I lean that way myself, but I'm a bit lazy at times. (Even if you put /sbin first in the search order, there's still the kind of problem where, say, you may be expecting to use /sbin/lvm on a machine where lvm is not installed, but some user has managed to put a rogue binary called lvm in /usr/bin.) >> Joao >> >> >>> Thanks with best regards, (Sorry about that last extra from me because of the CC, Tom.) -- Joel Rees -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/caar43ipuhyakukd00rgkbwks1xcfjmn2t+ks2pavpkcn-ms...@mail.gmail.com
Re: sbin
On Fri, Jan 6, 2012 at 3:42 AM, Tom H wrote: > On Sun, Jan 1, 2012 at 11:58 AM, Camaleón wrote: >> On Mon, 02 Jan 2012 00:42:10 +0800, lina wrote: >> >>> Is it safe to add /sbin into PATH? >> >> To you user env? If it's not an exposed system, I'd say yes. > > It's even OK on an "exposed" system. Having "(/usr)/sbin" in PATH for > everyone is the default for RHEL, Fedora, and Ubuntu and, anyway, the > executables in "(/usr)/sbin" are all "x" for "other". Somebody over there thinks that they should all be combined. Not sure why, but the fact that the current separation is historically derived from circumstance, not design, seems to figure large in the arguments. -- Joel Rees -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAAr43iOH=zy7t5o8njn3doygpaumv+nkuxvat+gpho1ta8r...@mail.gmail.com
Re: sbin
On Sun, Jan 1, 2012 at 11:58 AM, Camaleón wrote: > On Mon, 02 Jan 2012 00:42:10 +0800, lina wrote: > >> Is it safe to add /sbin into PATH? > > To you user env? If it's not an exposed system, I'd say yes. It's even OK on an "exposed" system. Having "(/usr)/sbin" in PATH for everyone is the default for RHEL, Fedora, and Ubuntu and, anyway, the executables in "(/usr)/sbin" are all "x" for "other". -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAOdo=Sy8m0jiMcBy32Y_mRbEr7QC4=h9-7zk85qbgqnqglb...@mail.gmail.com
Re: sbin
On Du, 01 ian 12, 13:19:13, Chris Brennan wrote: > > /bin > /sbin > > These two paths are set up and almost always linked to / (that being they > reside on the same partition/slice as the root partition,) so then in the > event > the system cannot mount anything but /, you will have a partially working > environment that would contain statically built binaries, allowing you to > fix > what ever broke and move on. No need for static linking since there is /lib ;) Kind regards, Andrei -- Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic signature.asc Description: Digital signature
Re: sbin
On 02/01/12 07:19, Chris Brennan wrote: > > Typically /bin is reserved for binaries executable by everyone on the > system, > whereas /sbin is *typically* reserved for binaries that are executable by > root > only, most of these would typically have the SETUID bit set for root as > well, > to further prevent non-root users from running them. The same logic would > extend to /usr/bin, /usr/sbin, and where the BSD's are concerned, > /usr/local/bin and /usr/local/sbin Um - the SETUID bit won't prevent non-root users running them. It will cause those binaries to be executed _as_ root, which is a totally different thing, and used as little as possible, and with great care. I think perhaps you meant to suggest that they might typically not be world- or group-executable, which would prevent non-root users running them - but they are in fact mostly world-executable, so that's not true either. The binaries can be executed by root, but often they will fail due to various permissions problems when a non-root user tries to run them. On my system, all files in /sbin and /usr/sbin are executable by all users, and only two (/sbin/mount.nfs and /usr/sbin/pppd) are setuid. Richard -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f00d082.30...@walnut.gen.nz
Re: sbin
This was intended for the list but accidentally got sent to only lina. -- Forwarded message -- From: Chris Brennan Date: Sun, Jan 1, 2012 at 12:01 PM Subject: Re: sbin To: lina On Sun, Jan 1, 2012 at 11:42 AM, lina wrote: > Hi, > > Is it safe to add /sbin into PATH? > > Why the default path not include /sbin, > > Thanks with best regards, Typically /bin is reserved for binaries executable by everyone on the system, whereas /sbin is *typically* reserved for binaries that are executable by root only, most of these would typically have the SETUID bit set for root as well, to further prevent non-root users from running them. The same logic would extend to /usr/bin, /usr/sbin, and where the BSD's are concerned, /usr/local/bin and /usr/local/sbin /bin /sbin These two paths are set up and almost always linked to / (that being they reside on the same partition/slice as the root partition,) so then in the event the system cannot mount anything but /, you will have a partially working environment that would contain statically built binaries, allowing you to fix what ever broke and move on. /usr/bin /usr/sbin These two paths are /typically/ used for normal system operation of system-related binaries. /usr/local/bin /usr/local/sbin Some Linux distro's utilize this, but it's the primary install location for BSD related OS's such as FreeBSD, NetBSD and/or OpenBSD (just to name a few). Any user-installed packages, either from binary or source, would get installed to this location, the idea being that the base system doesn't get cluttered and/or tainted by user-installed packages. > -- > Chris Brennan > A: Yes. > >Q: Are you sure? > >>A: Because it reverses the logical flow of conversation. > >>>Q: Why is top posting frowned upon? > http://xkcd.com/84/ | http://xkcd.com/149/ | http://xkcd.com/549/ > GPG: D5B20C0C (6741 8EE4 6C7D 11FB 8DA8 9E4A EECD 9A84 D5B2 0C0C)
Re: sbin
On 01/01/12 17:58, Camaleón wrote: On Mon, 02 Jan 2012 00:42:10 +0800, lina wrote: Is it safe to add /sbin into PATH? To you user env? If it's not an exposed system, I'd say yes. and if you really know what you do ! Why the default path not include /sbin, I guess this is a FHS recommendantion. if not one of the key point. Jerome Greetings, -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f00928d.50...@rezozer.net
Re: sbin
On Mon, 02 Jan 2012 00:42:10 +0800, lina wrote: > Is it safe to add /sbin into PATH? To you user env? If it's not an exposed system, I'd say yes. > Why the default path not include /sbin, I guess this is a FHS recommendantion. Greetings, -- Camaleón -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/pan.2012.01.01.16.58...@gmail.com
Re: sbin
On Monday 02,January,2012 12:50 AM, Joao Ferreira Gmail wrote: On Mon, 2012-01-02 at 00:42 +0800, lina wrote: Hi, Is it safe to add /sbin into PATH? there should be no problem, but a regular (non-root) user will not be able to do much with it because most of those executables will at some point require root privilege (at least that is my guess) Why the default path not include /sbin, On my system (Debian wheezy) I have it on root's PATH but not on regular user's PATH: root@wheejy:~# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin jmf@wheejy:~$ echo $PATH /home/jmf/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games tipically those commands are not used (not supposed to be used) by regular users. But I guess it won't hurt to add it to the PATH Thanks, I just checked, it's included in root PATH, not in user path. They really think so much to build a system. Joao Thanks with best regards, -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4f008f46.90...@gmail.com
Re: sbin
On Mon, 2012-01-02 at 00:42 +0800, lina wrote: > Hi, > > Is it safe to add /sbin into PATH? there should be no problem, but a regular (non-root) user will not be able to do much with it because most of those executables will at some point require root privilege (at least that is my guess) > > Why the default path not include /sbin, On my system (Debian wheezy) I have it on root's PATH but not on regular user's PATH: root@wheejy:~# echo $PATH /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin jmf@wheejy:~$ echo $PATH /home/jmf/bin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games tipically those commands are not used (not supposed to be used) by regular users. But I guess it won't hurt to add it to the PATH Joao > > Thanks with best regards, > > -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1325436630.6724.6.ca...@wheejy.critical.pt
Re: /sbin/reboot: symbolic link to `halt'
On Sun, Aug 16, 2009 at 9:22 PM, Sven Joachim wrote: > On 2009-08-16 22:36 +0200, Chris Bannister wrote: > >> I noticed that /sbin/reboot is a symbolic link to /sbin/halt. How does >> the system "know" the difference? > > The program notices how it is called and behaves accordingly. Programs > written in C can get information about their name in argv[0]. Well, the parent process sets argv[0], just like it sets argv[1] and following. The idea that argv[0] should be the name with which the program was invoked is just a convention. It's not a commonly broken convention, though. Login shells are started with '-' as the first character of argv[0]. The only other example I can think of is that ldd used to call programs with argc==0 and argv[0]==NULL in order to get the dynamic linker to spit out the list of shared libraries. These days, this is done differrently and argv[0] is no longer special on Linux from that point of view. Not sure when the changeover happened, it could be the a.out->ELF switch. James. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: /sbin/reboot: symbolic link to `halt'
On Sun, Aug 16, 2009 at 05:22:22PM -0300, Eduardo M KALINOWSKI wrote: > Chris Bannister wrote: > > Hi, > > > > I noticed that /sbin/reboot is a symbolic link to /sbin/halt. How does > > the system "know" the difference? > > > > By checking the name with which the program was called. In C it's > available as the first element in the array of command-line arguments > that the program receives; other languages have similar means. > > There are several programs that behave like this, a look at /usr/bin > will reveal others. Mmmm, should have worked that one out. :( I was on the wrong track thinking $0 was used by bash to find which program to pass the rest of the arguments to. Thanks Sven and Eduardo. -- Chris. == I contend that we are both atheists. I just believe in one fewer god than you do. When you understand why you dismiss all the other possible gods, you will understand why I dismiss yours. -- Stephen F Roberts -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: /sbin/reboot: symbolic link to `halt'
On 2009-08-16 22:36 +0200, Chris Bannister wrote: > I noticed that /sbin/reboot is a symbolic link to /sbin/halt. How does > the system "know" the difference? The program notices how it is called and behaves accordingly. Programs written in C can get information about their name in argv[0]. Sven -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: /sbin/reboot: symbolic link to `halt'
Chris Bannister wrote: > Hi, > > I noticed that /sbin/reboot is a symbolic link to /sbin/halt. How does > the system "know" the difference? > By checking the name with which the program was called. In C it's available as the first element in the array of command-line arguments that the program receives; other languages have similar means. There are several programs that behave like this, a look at /usr/bin will reveal others. -- The major difference between bonds and bond traders is that the bonds will eventually mature. Eduardo M KALINOWSKI edua...@kalinowski.com.br -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Re: /sbin/ifconfig shows eth0, but not "RUNNING"?
[EMAIL PROTECTED] wrote: On Fri, Oct 25, 2002 at 02:33:58PM -0700, Adar Dembo wrote: I am trying to run a piece of software that apparently depends on a "RUNNING" message in ifconfig. dh3:/etc/tss2# /sbin/ifconfig eth0 Link encap:Ethernet HWaddr 00:E0:18:2A:00:59 inet addr:128.12.19.34 Bcast:128.12.255.255 Mask:255.255.0.0 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:182004968 errors:0 dropped:0 overruns:0 frame:0 TX packets:107471612 errors:0 dropped:0 overruns:227 carrier:0 collisions:0 txqueuelen:100 RX bytes:2692733011 (2.5 GiB) TX bytes:3770438040 (3.5 GiB) Interrupt:20 loLink encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:10143 errors:0 dropped:0 overruns:0 frame:0 TX packets:10143 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:1291706 (1.2 MiB) TX bytes:1291706 (1.2 MiB) Notice how the loopback interface has "RUNNING" on it, whereas eth0 does not. It is the lack of RUNNING that is preventing the software I'm trying to run from loading. It claims that eth0 is NOT running, which, according to ifconfig, it isn't. What should I do? -Adar PS I'm not subscribed to the list, so please respond directly to my e-mail address It is RUNNING for me. Does the interface working? Can you ping somewhere else? Yes. The interface works fine for everything. Apache is one of many services running there that is heavily accessed by others, and the fact it doesn't say RUNNING doesn't change a thing. The interface DOES work. -Adar -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /sbin/ifconfig shows eth0, but not "RUNNING"?
On Fri, Oct 25, 2002 at 02:33:58PM -0700, Adar Dembo wrote: > I am trying to run a piece of software that apparently depends on a > "RUNNING" message in ifconfig. > > dh3:/etc/tss2# /sbin/ifconfig > eth0 Link encap:Ethernet HWaddr 00:E0:18:2A:00:59 > inet addr:128.12.19.34 Bcast:128.12.255.255 Mask:255.255.0.0 > UP BROADCAST MULTICAST MTU:1500 Metric:1 > RX packets:182004968 errors:0 dropped:0 overruns:0 frame:0 > TX packets:107471612 errors:0 dropped:0 overruns:227 carrier:0 > collisions:0 txqueuelen:100 > RX bytes:2692733011 (2.5 GiB) TX bytes:3770438040 (3.5 GiB) > Interrupt:20 > > loLink encap:Local Loopback > inet addr:127.0.0.1 Mask:255.0.0.0 > UP LOOPBACK RUNNING MTU:16436 Metric:1 > RX packets:10143 errors:0 dropped:0 overruns:0 frame:0 > TX packets:10143 errors:0 dropped:0 overruns:0 carrier:0 > collisions:0 txqueuelen:0 > RX bytes:1291706 (1.2 MiB) TX bytes:1291706 (1.2 MiB) > > Notice how the loopback interface has "RUNNING" on it, whereas eth0 does > not. It is the lack of RUNNING that is preventing the software I'm > trying to run from loading. It claims that eth0 is NOT running, which, > according to ifconfig, it isn't. What should I do? > > -Adar > > PS I'm not subscribed to the list, so please respond directly to my > e-mail address > It is RUNNING for me. Does the interface working? Can you ping somewhere else? -- Shaul Karl, [EMAIL PROTECTED] e t -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /sbin/ipchains: host/network `domain.name' not found - SOLVED
Sorry to be posting a followup to my own question, but I solved this. I was using ipmasq to set up rules which needed to resolve external domain names before actually allowing external traffic... A bit stupid, but there it is. Putting my rules in post-processing rules files: /etc/ipmasq/P30internal.rul /etc/immasq/P90external.rul which are executed after the internal and external input files in which I initially put them: /etc/ipmasq/I30internal.rul /etc/ipmasq/I90external.rul solved it. > I'm running Debian GNU-linux 2.2r3 (potato) and trying to set up firewall > rules with sources and destinations specified as domain names rather than > IP addresses. > > The problem is that ipchains returns an error: > > /sbin/ipchains: host/network `domain.name' not found > Try `/sbin/ipchains -h' or '/sbin/ipchains --help' for more information. > > The host this is running on can resolve the domain names OK. > > Anyone know what could be wrong? > > Thanks and best regards, > George Karaolides 8, Costakis Pantelides St., tel: +35 79 68 08 86 Strovolos, email: [EMAIL PROTECTED] Nicosia CY 2057, web: www.karaolides.com Republic of Cyprus
Re: /sbin and /usr/sbin be in a normal user's path ?! What about Sudo ?
On Wed, Dec 29, 1999 at 11:46:39AM +0800, Bernd Eckenfels wrote: [...] > -> > > e) our recommended solution wold be to install traceroute in bin (i already > repored that as an error half year ago) > > BUT > > f) our recommended solution would break scripts which use a hardwired > /usr/sbin to traceroute > > -> > > g) our solution to this would be to move traceroute AND leave a symlink from > the old location pointing to the newe one > > I dont see what sudo has to do with that > I sort of do ... when you use sudo, it uses the root command path. The problem with that is that sudo also gives the user root privileges, which we may not want by default. I think that the best solution is a temporary symlink. Anything that breaks gets a bug filed against it with a patch and everything. It would be easy, even, to write a script that uses zgrep -srl sbin/traceroute to file a bug against every file on the system (or in an archive) that has such a reference. You could probably even submit a patch, since most such errors will be either bash or perl scripts. Make the patched versions depend on the moved traceroute (>= whatever version). When all of the bugs are closed, remove the symlink. Out of curiosity, what don't people like about symlinks? > (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! Does this say, then persons will like anchovies? That doesn't make much sense at all ... Rob -- The hardest thing in the world to understand is the income tax. -- Albert Einstein
Re: /sbin and /usr/sbin be in a normal user's path ?! What about Sudo ?
On Wed, Dec 29, 1999 at 02:52:27AM +0100, Olivier Lemaire wrote: > I effectively disagree the idea of symlinks. Why don't we make a sudo package > included in the base install ? > I mean a "debian-customised" package who should be integrated in the > base system . Eventually, like shadows passwords are included . I guess u missed the topic here: a) traceroute is in /sbin (traceroute6 is in /usr/bin) b) normal users can execute /usr/sbin/traceroute (since it IS suid root) c) normal users need to put /usr/sbin in their path to execute this program d) FHS recommends to put in sbin only programs a normal (non admin) user dont want to use -> e) our recommended solution wold be to install traceroute in bin (i already repored that as an error half year ago) BUT f) our recommended solution would break scripts which use a hardwired /usr/sbin to traceroute -> g) our solution to this would be to move traceroute AND leave a symlink from the old location pointing to the newe one I dont see what sudo has to do with that Greetings Bernd -- (OO) -- [EMAIL PROTECTED] -- ( .. ) [EMAIL PROTECTED],linux.de,debian.org} http://home.pages.de/~eckes/ o--o *plush* 2048/93600EFD [EMAIL PROTECTED] +497257930613 BE5-RIPE (OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl! -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: /sbin and /usr/sbin be in a normal user's path ?! What about Sudo ?
On Wed, Dec 29, 1999 at 09:58:29AM +0800, Olivier Lemaire wrote: > Greetings :) Hi > I saw in the DWN : > "Should /sbin and /usr/sbin be in a normal user's path so they can > easily run traceroute [...] > > [..] Why don't we make a > sudo package included in the base install ? It may be my fault but I don't see what sudo has to do with this issue. Could you please explain? -- Weaselhttp://www.cosy.sbg.ac.at/~ppalfrad/ PGP/GPG encrypted messages prefered. See my site or finger -l ppalfrad -- Yes means No and No means Yes. Delete all files [Y]? pgpDsmfN9HDoz.pgp Description: PGP signature
Re: /sbin/clock missing?
Anthony Fok <[EMAIL PROTECTED]> writes: > On 1 Jan 1998, William R Ward wrote: > > Until I upgraded to hamm, I could use /sbin/clock to set and view the > > CMOS clock. That program is gone now! Did something else replace it? > > Yes! :-) /sbin/hwclock is the new program that replaces the obsolete > /sbin/clock. The syntax is different too, so make sure you read the > manpage. :) Thanks! Actually the manpage says it has the same options for backwards compatibility; just the same, I used the new -- options. I run a cron job that grabs the date from my net gateway nightly and then stores that in the hardware clock. --Bill. -- William R Ward Bay View Consulting http://www.bayview.com/~hermit/ [EMAIL PROTECTED] 1803 Mission St. #339voicemail +1 408/479-4072 [EMAIL PROTECTED] Santa Cruz CA 95060 USA pager +1 408/458-8862 PGP Key 0x2BD331E5; Public key at http://www.bayview.com/~hermit/pubkey.txt -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /sbin/clock missing?
On 1 Jan 1998, William R Ward wrote: > Until I upgraded to hamm, I could use /sbin/clock to set and view the > CMOS clock. That program is gone now! Did something else replace it? Yes! :-) /sbin/hwclock is the new program that replaces the obsolete /sbin/clock. The syntax is different too, so make sure you read the manpage. :) Happy New Year! Anthony -- Anthony Fok Tung-Ling[EMAIL PROTECTED] Civil Engineeringhttp://www.ualberta.ca/~foka/ University of Alberta, CanadaKeep smiling! *^_^* -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /sbin/clock status?
Randy, /sbin/clock has been replaced by /sbin/hwclock. Steve Mayer [EMAIL PROTECTED] Randy Edwards wrote: > Does anyone know what happened to the nifty little clock program that > used to be in /sbin/clock? I used that to set my CMOS clock time from > the OS' time but since I updated to hamm I can't seem to find it. A > grep of Contents-i386 doesn't seem to show it either. Anyone know its > status? Thanks in advance. > > -- > Regards, | Debian GNU/ __ o > .|/ / _ _ _ _ _ __ __ > Randy| / /__ / / / \// //_// \ \/ / > ([EMAIL PROTECTED]) | // /_/ /_/\/ /___/ /_/\_\ > | ...because lockups are for convicts... > > -- > TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to > [EMAIL PROTECTED] . > Trouble? e-mail to [EMAIL PROTECTED] . -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /sbin/clock status?
On Wed, 31 Dec 1997, Randy Edwards wrote: > Does anyone know what happened to the nifty little clock program that > used to be in /sbin/clock? I used that to set my CMOS clock time from > the OS' time but since I updated to hamm I can't seem to find it. A > grep of Contents-i386 doesn't seem to show it either. Anyone know its > status? Thanks in advance. It has been replaced with hwclock, which has a slightly different option set. -- Scott K. Ellis <[EMAIL PROTECTED]> http://www.gate.net/~storm/ -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /sbin/dump unable to resolve 'ext2_llseek'
Joerg Delker writes: > Norris Preyer wrote: > > Douglas Bates writes: > > > On Tuesday I installed several updated packages from bo. I noticed > > > this morning that file system dumps have been failing since then. > > Downgrading e2fsprogs to 1.06-3 (in stable) fixed dump for me. > > Well, it solved the symbol-problem, but brought me a new error: > > | DUMP: Date of this level 0 dump: Sat May 3 00:54:35 1997 > | DUMP: Date of last level 0 dump: the epoch > | DUMP: Dumping /dev/hda5 (/home) to standard output > | DUMP: mapping (Pass I) [regular files] > | DUMP: mapping (Pass II) [directories] > | DUMP: estimated 145102 tape blocks. > | DUMP: dumping (Pass III) [directories] > | DUMP: master/slave protocol botched. > | DUMP: The ENTIRE dump is aborted. > > Any Idea on that? > > -- > +--+ > | EINSTEIN Joerg Delker, DataBaseAdmin (dbguru) E3.148, Tel.: 3318 | > | University of Paderborn, Computer Science | > | e-mail: [EMAIL PROTECTED] - [EMAIL PROTECTED] | > | Bayernweg 64, 33102 Paderborn, Germany, Tel.: +49 5251 480578| > +--+ > I've not seen the master/slave message before and don't know what it means. The lastest packages from unstable seem to work fine now, so you might want to try upgrading and see if things improve. This is what I've been using successfully: # dpkg -l dump e2fsprogs Desired=Unknown/Install/Remove/Purge | Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed |/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad) ||/ NameVersionDescription +++-===-==- ii dump0.3-14 Ported 4.4BSD dump and restore utilities. ii e2fsprogs 1.10-2 The EXT2 file system utilities. # HTH, Norris -- Norris Preyer (541) 962-3310 (office) Physics Program (541) 962-3873 (fax) Eastern Oregon University [EMAIL PROTECTED] La Grande, OR 97850http://140.211.64.20/npreyer.html -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /sbin/dump unable to resolve 'ext2_llseek'
Norris Preyer wrote:
>
> Douglas Bates writes:
> > On Tuesday I installed several updated packages from bo. I noticed
> > this morning that file system dumps have been failing since then.
> > Here is a dummy run of /sbin/dump to show the symptoms.
> > franz# /sbin/dump 0f /dev/null /spare1
> > DUMP: Date of this level 0 dump: Thu May 1 17:13:35 1997
> > DUMP: Date of last level 0 dump: the epoch
> > DUMP: Dumping /dev/hda1 (/spare1) to /dev/null
> > DUMP: mapping (Pass I) [regular files]
> > DUMP: mapping (Pass II) [directories]
> > DUMP: estimated 41266 tape blocks on 1.06 tape(s).
> > DUMP: dumping (Pass III) [directories]
> > DUMP: dumping (Pass IV) [regular files]
> > /sbin/dump: can't resolve symbol 'ext2_llseek'
> > /sbin/dump: can't resolve symbol 'ext2_llseek'
> > /sbin/dump: can't resolve symbol 'ext2_llseek'
> > DUMP: Interrupt received.
> > DUMP: Do you want to abort dump?: ("yes" or "no") yes
> > DUMP: The ENTIRE dump is aborted.
> >
> > Any suggestions on what has gotten out of sync? Even better, any
> > suggestions on how to repair the problem?
> >
>
> Downgrading e2fsprogs to 1.06-3 (in stable) fixed dump for me.
Well, it solved the symbol-problem, but brought me a new error:
| DUMP: Date of this level 0 dump: Sat May 3 00:54:35 1997
| DUMP: Date of last level 0 dump: the epoch
| DUMP: Dumping /dev/hda5 (/home) to standard output
| DUMP: mapping (Pass I) [regular files]
| DUMP: mapping (Pass II) [directories]
| DUMP: estimated 145102 tape blocks.
| DUMP: dumping (Pass III) [directories]
| DUMP: master/slave protocol botched.
| DUMP: The ENTIRE dump is aborted.
Any Idea on that?
--
+--+
| EINSTEIN Joerg Delker, DataBaseAdmin (dbguru) E3.148, Tel.: 3318 |
| University of Paderborn, Computer Science |
| e-mail: [EMAIL PROTECTED] - [EMAIL PROTECTED] |
| Bayernweg 64, 33102 Paderborn, Germany, Tel.: +49 5251 480578|
+--+
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] . Trouble?
e-mail to [EMAIL PROTECTED] .
Re: /sbin/dump unable to resolve 'ext2_llseek'
Norris Preyer <[EMAIL PROTECTED]> writes:
> Douglas Bates writes:
> > Here is a dummy run of /sbin/dump to show the symptoms.
...
> > /sbin/dump: can't resolve symbol 'ext2_llseek'
> > /sbin/dump: can't resolve symbol 'ext2_llseek'
> > /sbin/dump: can't resolve symbol 'ext2_llseek'
> > DUMP: Interrupt received.
> > DUMP: Do you want to abort dump?: ("yes" or "no") yes
> > DUMP: The ENTIRE dump is aborted.
> >
> > Any suggestions on what has gotten out of sync? Even better, any
> > suggestions on how to repair the problem?
> >
>
> Downgrading e2fsprogs to 1.06-3 (in stable) fixed dump for me.
It looks like the problem is a name mismatch. The symbol that
/sbin/dump wants to find is "ext2_llseek" but the symbol in
/lib/libext2fs.so.2.3 is "ext2fs_llseek".
I tried to recompile /sbin/dump from the source package but was
unsuccessful. It appears that one of the main include files,
/usr/include/ctype.h, is broken. I'll have to fix that first.
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
Re: /sbin/clock not ticking
On 27 Apr 1997, Rob Browning wrote: > Mark Phillips <[EMAIL PROTECTED]> writes: > > > I don't know what /dev/rtc is, but it seems that on my brother's computer > > it can't be opened. It seems that this in turn allows clock to work. > > Most likely it can't be opened because that device was not compiled > into his kernel, but it was into yours. > > > The strange thing is that /dev/rtc does in fact exist on my brother's > > computer (and on mine). > > Whether or not the device exists in the kernel has nothing to do with > whether or not the device file exists on disk. For example, if I > compiled a kernel without sound support, the file /dev/audio might > still exist, but if I tried to open it, the open would fail. > > As to why having rtc in the kernel would cause clock to fail, I have > no clue. > > -- > Rob I think rtc is for Real Time Clock It was an option for kernel configuration. I don't know what it is exactly, but the help said that you don't need it if you don't know what it is. It could interfere or be buggy. Try without. That was my 2 Pfennig Alexandre -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /sbin/clock not ticking
Mark Phillips <[EMAIL PROTECTED]> writes: > I don't know what /dev/rtc is, but it seems that on my brother's computer > it can't be opened. It seems that this in turn allows clock to work. Most likely it can't be opened because that device was not compiled into his kernel, but it was into yours. > The strange thing is that /dev/rtc does in fact exist on my brother's > computer (and on mine). Whether or not the device exists in the kernel has nothing to do with whether or not the device file exists on disk. For example, if I compiled a kernel without sound support, the file /dev/audio might still exist, but if I tried to open it, the open would fail. As to why having rtc in the kernel would cause clock to fail, I have no clue. -- Rob -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /sbin/clock not ticking
I wrote:
> When I try and set the CMOS clock I get the following error:
>
> # /sbin/clock -u -w
> ioctl: Invalid argument
Someone kindly suggested I run "strace clock". I am not familiar with
strace, but it did seem to give some potentially useful information.
I tried running clock on my brother's computer (also running debian) and
it works fine on his system. I compared the strace from his clock with
the output from mine. There were a few differences, but the most relevant
was:
My brother's output:
open("/dev/rtc", O_RDONLY) = -1 ENODEV (No such device)
iopl(0x3) = 0
My output:
open("/dev/rtc", O_RDONLY) = 3
ioctl(3, 0x7003, 0) = -1 EINVAL (Invalid argument)
write(2, "ioctl: Invalid argument\n", 24ioctl: Invalid argument) = 24
I don't know what /dev/rtc is, but it seems that on my brother's computer
it can't be opened. It seems that this in turn allows clock to work.
The strange thing is that /dev/rtc does in fact exist on my brother's
computer (and on mine).
On my brother's computer:
# ls -laF /dev/rtc
crw-rw-rw- 1 root sys 10, 135 Jan 1 1970 /dev/rtc
All very strange.
The other thing of possible interest is that my brother's computer
opens an older version of libc.so:
open("/lib/libc.so.5.4.13", O_RDONLY) = 3
Whereas on my computer:
open("/lib/libc.so.5.4.23", O_RDONLY) = 3
I don't know whether this would have anything to do with it? Any help
would be greatly appreciated.
Thanks.
-
Mark Phillips [EMAIL PROTECTED]
"They told me I was gullible ... and I believed them!"
-
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
[EMAIL PROTECTED] .
Trouble? e-mail to [EMAIL PROTECTED] .
