Agreed. IMHO it is a very bad idea to run your unit as root. I think one should run their unit as a regular user and when needed invoke su and get root privileges. If you wreck your user account you can always create another user.....but.....if you torch your root account....well, heh-heh, it isn't pretty:-)

IMHO it must not run root account directly. You can obtain root privileges by typing su and provide root password.

Type nmap localhost and watch the output. Look into your /etc/host.allow and /etc/host.deny file. Type netstat -teanpl and watch how many connections are in "Established" state, with user 0. You can also run something like TARA and read the report. Take a look in /etc/ssh/sshd_config too. These are only a few things for why it is not a good idea to use your root account.

Nobody will attack your computer. But who knows? Why after that to regret that you forgot the 631/tcp port open and you don't even have a printer?

Exactly the point Pappy.

This post summarises it nicely:
http://www.linuxquestions.org/questi...=455623&page=2

Another good quite from that thread: "Running as root could be likened to running a table saw without the blade guard. It is completely feasible but, statistically, you will eventually get bitten."

Why are you guys so worried about whether or not pappy_mcfae runs his system as root? Who cares? It's his choice, let him make it & you make your own. This thread started out as a very good discussion of 12.0 & hal, but look what it has deteriorated into. I suggest that it be unstickied & allowed to sink into the morass where it belongs.
Regards,
Bill

That is what I'd like to know. I realize that there is a risk involved in operating as root. Of course there is. There is also a risk (a bigger one considering where I live) of me getting splattered by some bimbette in an SUV blathering on her cell phone! There is also a greater risk of me getting hit by a tornado (came close twice so far), getting mugged walking out of my apartment, or having a heart attack than there is me killing my Linux installation because I am the root user.

I have run my Windoze NT-derived machines as "administrator" since day one of installation (also supposedly a bad idea). I have yet to kill them. I tend to upgrade them.

As a matter of fact, until about three months ago, I had a machine that had been running the same operating system set up for almost six years. It started life as NT workstation, morphed to NT server, then Win2k server. That particular setup had lived on two different IDE, and four different SCSI drives, and had survived being transfered from disk to disk to disk WITHOUT Ghost. I only got rid of the setup because the drive on which it was living was starting to crash.

It was a good thing, really. That particular system had picked up a large amount of glitches over time, and as it had been upgraded. It was time to refresh it. I think six years is about as long as anyone should run a particular operating system.

If I can keep a Windoze setup alive and kicking for six years, that pretty much means I'll have the same luck with my Slackware six years from now if I don't get rid of because of upgrading to something better, or newer.

I also agree that this thread should be dropped, but for a different reason: much of it is based in speculation. The first few pages have some really helpful stuff. Unfortunately, some of the posts here also have incorrect information. Still others are incredibly off topic. It might be a good idea to distill the useful stuff from this discussion, and leave out the rest.

I have been working on and with computers since I had a TI-99/4A. I have been working on and with REAL computers since the time that DOS 6.22 and Windoze 3.11 filled millions more hard drives than Linux could even hope to see. I have been repairing computers, setting up networks, and otherwise playing with them since the time when Linux was new. I may not be an ultra-geek, but I think I know a few things. One can't work with something for all those years without learning a few things.

So I don't really understand the idea being floated here that for some reason, I don't understand the ramifications of working as a root user. I know them all too well, having set up several Linux distros that lack the root user account altogether.

I know what it's like to be denied access to my entire directory tree. I don't like being locked out of my own computer, except for the directories that the operating system decides it will allow me to change.

Operating as root may not be the wisest idea, but that doesn't mean it's completely wrong. I am willing to bet there are folks out in the world who have had stable Linux installations over two years old that have had only the root user from day 1. If it comes to a place in my reality where I make money with Linux, then I'll set up a non-root user account. Until then, nothing anyone says here will make me change my computing habits.

I set up Slackware all by myself. I set it up in 1994, before many others here even knew what it was. I gave up on it because it was more of a curiosity than it was a moneymaker. I specialized in OS/2, Windoze NT 3.5, and DOS and Windoze 3.11. I became familiar with them all, because that's what the customers used. Finally, I rediscovered Linux as more of a hobby.

I don't make money with it. None of my business software runs on it. It is something I do for fun. I have installed PHLAK 0.28 and 0.30, Ubuntu, Kubuntu, Debian, Ark Linux, Vector Linux, Fedora, Solaris, and a few others, and had them all functional! I think it could be said I may be a newbie in number of posts here, but I am not a newbie when it comes to working with computers or the software that makes them work, Linux included.

You might say this is far from my first time at the rodeo. So I fail to see why people insist on warning me about how I choose to use MY machines. This is especially true when one considers this isn't the first time I have shared my computer pedigree here. I am not a rank amateur. And for those who will quip that my use of the root account speaks otherwise, I say that when I rode a motorcycle, I only put on a brain bucket when forced to by state law.

I am an adult, and therefore I am capable of understanding the risks involved in life; whether it's real life, or computing life. I am a big boy (literally). I know what I am doing. AND, if every one of my Slackware installation did decided to die tomorrow, I'd have everything back up and running in a day.

So would y'all P-L-E-A-S-E stop giving me grief over this issue? It's starting to get on my nerves. I don't get this much flack from OpEdNews.com, and I go there specifically to debate REALLY contentious issues like politics and religion. I come here to learn about Linux, share what I know, and to discuss Linux related issues. When this crap happens, the moderators get on me for defending myself, and the whole experience takes on a really sucky sheen for me. So please stop!

Can't we all just get along?

Blessed be!
Pappy

PS: If y'all R-E-A-L-L-Y want to discuss the moral and geopolitical issues involved in running as a root or not, start a thread about it, m'kay? I'll gladly add my two cents to that thread.

Well-said. Agreed.
I know the chances are slim with having your desktop or server owned by some miscreant when you're running as root.
But, why chance it?

Because he chooses to. Why question his choice?
Regards,
Bill

He is perfectly free and clear to run his unit as he chooses, I'm not disputing that. I support his right to do what he wants!
I worry that an inexperienced user on this forum will read the comments of a long time computer user and think it is safe to run a Linux box as root and follow his example. I think new Slackers on this forum should be aware of the risks.
It is not a good idea, IMHO.

Back on topic, HAL works on my computer (Slackware 12.0, generic 2.6.21.5-smp kernel) by adding my user in /etc/group configuration file:
Nothing else more.

For NTFS partitions I installed ntfs-3g and fuse packages and I edited /etc/fstab file
because I'm not sure that it's a good idea to add my user name to group

You know what newcomers do? Everything wrong that everyone else did wrong. Do you know how people learn they are doing stupid things, and begin to stop doing them? They make mistakes, crash cars, bad parties, and hard drive heads. If you think that you can protect a newbie from themselves, you are as clueless as the parent that thinks their teen-aged brats are actually paying attention to what they are being told.

Do you know how I learned what I know about computers? I killed two and resurrected them from their ashes. Are you going to deny someone the right to do this just so they don't have to deal with the "pain" of losing data that's probably worthless to begin with?

Besides all that, how many times do I need to have my intellect and the way I use my computer questioned by people who aren't even living with me? If a newbie can't get that there is a data risk by running as root, then it's not my fault, or the fault of anyone else here. It's the fault of not snuffing out stupid from the Human Genome!

The most common cause for computers crapping out is hardware failures. Even if a newbie does all that is expected, one sideways bump of their machine while the hard drive is accessing can send their just finished software setup to the place where the digital angels hang out. One flaky resistor in the power supply can render the machine worthless. One errant cockroach taking a dump on the DMA controller chip can destroy not only data, but hardware as well.

Granted, running as root goes against common wisdom. Oh well, so does a lot of the other things I do on a daily basis. That's why I am an individual.

People cannot (and IMHO, SHOULD NOT) be protected from themselves. The only way to garner wisdom and experience in life is to live it, and make mistakes. Eventually, one will come to a place where they begin to understand the ramifications of life. This constant worry about what the newbie or other inexperienced people will do is total BS! How on earth are people to be expected to use their brains as more than ear spacers if they aren't challenged, and don't fail?

I learn the most when I fail! I learned it's stupid to pull the data cable from an MFM hard drive while the drive is accessing by doing so, and crashing a lot of old data...data for which there was no backup. You know what? I NEVER DID THAT AGAIN! UH DUH! Did I lose anything from that experience? Yeppers, but nothing that couldn't be replaced.

So give it a rest, or start a separate thread about it, M'kay?

Blessed be!
Pappy

No argument from me.

Also, as the original author of this thread, I respectfully request of everyone that we let this secondary (tertiary, even?) discussion die.

Will do. My apologies Robby!

I've found that the groups cdrom, plugdev,audio, video, and wheel are sufficient for my needs.

I am SOOOOO with you on this point!

So what have we learned about hal and Slackware 12?

1) There are some bugs in Slack-12, as with any other software package.
2) These bugs do have cures, and once cured, Slack-12 is as stable as any former version of Slackware.
3) The key to getting hal to work as expected is to use an smp enabled kernel and initrd.
4) In order to gain access to your optical media drives and native Linux partitions, you must place your user name in the /etc/group file after plugdev and cdrom.
5) While conventional wisdom says it is a good idea to operate as a non-root user, operating as the root user is not a detrement to the operation of hal and konqueror.

Further amplification:

1) There are some bugs in Slack-12, as with any other software package.

Some of the bugs that have been noted with Slack-12 are as follows: Xorg's video drivers for the Intel i810 video card somehow morph to sil64 drivers. Xorgestup is apparently unable to detect a laptop's LCD monitor, and sets the vertical refresh rate over 60 Hz. This causes problems with setting up laptops. Also, the fonts don't register properly in some programs. The one I noticed above all others was Firefox.

2) These bugs do have cures, and once cured, Slack-12 is as stable as any former version of Slackware.

There are cures outlined in separate threads here in the Slackware forum that address all the above. Then there is this one that specifically addresses the hal problems...

3) The key to getting hal to work as expected is to use an smp enabled kernel and initrd.

As proved by my experimentation, the kernel used must be compiled with smp support. I didn't check to see if you can get away with setting up smp support as a module, so I am not sure if the smp support must be compiled into the kernel, or will work as a module. I invite someone with a faster system than I to see if such is the case. I am interested to know one way or another. My assumption is that as long as the kernel supports smp, it doesn't matter whether that support is compiled into the kernel, or is set up as a module. I'd love to know one way or another.

The kernel need not have the "smp" moniker in the its name. If you have a kernel that you had compiled for use with Slack-11 that is 2.6.21.5 or higher, all you need to do to be able to use it with Slack-12 is make sure it's set up to support smp. If the kernel you have already supports smp, you need to set up initrd.

Apparently, you need only set up initrd with support for the Linux native file system. Doing so will most likely cause an error message to be generated at boot time. However, it is also apparent that the error message doesn't cause any problems in computer operation. If your machine can support an smp kernel, you are all set, if not...? Fortunately, all my machines support smp, even the lowly PII tower sitting at my feet.

4) In order to gain access to your optical media drives and native Linux partitions, you must place your user name in the /etc/group file after plugdev and cdrom.

Having the smp enabled kernel is only part of the story. The name of the user must be added to the /etc/group file after the entries for cdrom and plugdev in order to gain full access to your media when you are using KDE, and to a smaller degree, Dropline Gnome.

5) While conventional wisdom says it is a good idea to operate as a non-root user, operating as the root user is not a detrement to the operation of hal and konqueror.

As we have all learned through watching the beating of this dead horse, the user name added to the /etc/group file is immaterial, as long as that user name is added to the cdrom and plugdev groups. Hal and Slack-12 does not differentiate between user names. All are valid, even "root".

Is that about it, or have I forgotten something?

Blessed be!
Pappy

That's probably it -- but I don't get any errors whatsoever after creating an initrd.gz file (using the stock generic kernel). The only thing I can think of is that you compiled filesystem support into kernel (not as a module) and still try and load it using an initrd.gz. Also, most processors should support the smp kernel even if it is a uniprocessor (I'm not sure how many exceptions to this exist).

Hmm, none of the above suggestions have produced results on my system (laptop upgrade from slackware 11 - 12), despite following the upgrade instructions, trying the smp kernel with an initrd, adding users to the correct groups, /dev/cdrom commented out of fstab, and the DBUS and HAL daemons running (plus ...messagebus reload just for good measure).
With /dev/cdrom uncommented in fstab, Konqueror returns the error, 'Feature only available with HAL,' when attempting to mount /dev/cdrom from the desktop or from within konqueror.

I thought for a while that old 11.0 configurations may be preventing HAL from integrating with Konqueror. Is that a possibility? A fresh install on my PC works perfectly. (a clean install on my laptop is too time consuming at the moment, and I would like to understand this upgrade issue).

In summary, hald is not adding a device object - cannot resolve keypath - cannot get uid for connection or UID of name org..DBus.Error.NameHasNoOwner Could not get UID of name org..DBus: no such name. Cannot get caller info for org..Dbus.

This may seem to indicate that the problem possibly lies with the uid naming issue assw DBus. Any ideas?