Bashscripts.org

Hey guys...

I was running FC5, got a wild hair and decided to install SuSE 10.1. I don't know whether or not it was a good move yet, but we'll see.

I'm having problems with my wireless card. The module for ndiswrapper is loading at boot time but I have to run 'dhclient wlan0' or 'ifup wlan0' in order to get online. While I was running FC5 I didn't have any problems and it seems that SuSE is being a bit more strict concerning permissions. If I run dhclient or ifup as 'root' I don't have a problem but as a normal user, it doesn't allow it.

I wrote an a very small script and this worked in FC5 but not in SuSE.



Simple enough.

I'm getting error messages like crazy and I won't list them here becasue the list is too long. Basically what I'm wanting to do is
run the script I wrote while logged in as a normal user and not have it give me errors concerning permissions.

Is there a way to implement something in the above script to have it run as 'root' without having to 'su' at the command line??

Thanks

when scripting... and needing root... I would HIGHLY suggest setting up sudo.

its very easy... and very flexible. best of all.. you can make it so that this particular script doesn't need a password to run

first make sure you have sudo installed (I think suse does by default... but who knows)

once you are sure it is (type sudo to find out) *as root* run "visudo" (it uses the vi editor)

I would suggest making *just* the script executable through sudo without a password... just for security reasons

the line in the sudoers file would be:


or if you wanted an entire directory to hold your scripts that have to be run as root... try:


I'm sure there may be a better way... but I *know* this works

jbsnake,

Its little things like that...I appreciate it. I don't ever want to be a pest here or in any other forum...I don't want to always come in here and ask a ton of silly little questions. The little things will eventually add up and before I know it, I may actually know something!

I have a little hangup now. While running the aforementioned script, I got 'visudo' to let the normal user 'bob' run '/sbin/dhclient' and remove the existing dhclient.pid in /var/run. What 'dhclient wlan0' wants to do next is 'Open a socket for LPF' and I get the error
Operation not permitted. I don't have a clue on that.

Up to that point your advice worked and, as I said before, I really appreciate your help. I know I could 'su' from the CL, but that, in my opinion, at this point, would be cheating. I wouldn't learn anything like that.

Any ideas?

I don't bother with sudo................Instead, I use a simple function in it's place, which I call 'rootcmd', and put it in my .bashrc script.....Here's what it looks like:
To use it, simply call the function and enter the root password:

What this does is run the command as root, and when it's done you are right back where you started, a normal user....

To apply this in your script, you could do this:
When running the script, you will be asked for the root password, the script runs with complete root privileges (as root), and immediately drops back as a normal user when finished......

Try it and see if it works any better....

---thegeekster


PS: You'll still need to run it from the command line, but this will minimize su'ing to root only for the time required to run the script, and no more......

To the geekster,

That worked perfectly. Many thanks!!!

when changing your script, did you make changes to both lines?
can i see the code you had for the script you were using sudo on, and can i see how you called the script?
there is no reason sudo wouldn't have worked... and to be perfectly honest... the whole point of using sudo was to keep from entering the root password... or so i thought

jbsnake,

I didn't keep a copy of that script the way it was, but if I remembert correctly, it was as follows:



Logged in as a normal user ('bob', thats me! ), after running visudo, it allowed me to run the script and it executed 'dhclient' and 'ifup' but
it seems that one or both of those create another process or processes and it wouldn't allow it to continue...So, needless to say, I don't have a clue.

I have since fixed the main problem. I used to use that script in FC5 but I have installed SuSE 10.1 and the ndiswrapper module tainted the kernel and it would load on boot. So, I had to modprobe ndiswrapper everytime I started the laptop in order to get on line. I did however find a boot script for ndiswrapper and now it loads at boot time and I have no problems. I'm finding that SuSE is totally different than Fedora and I have a little learning to do.

To be honest, I have so many things going on at once in Linux that my head is spinning!!! But, I switched to Linux a while back because I wanted to use a computer to learn about it, and Windows seems to do everything for you. Not the case with 'nix!!!

Just a thought: sudo is safer than the 'rootcmd' that theGeekster proposed as you already found out. It's important to do what works for you but be careful how you use that rootcmd script because you find yourself accidentally doing something ('cause you can) when you didn't mean to in a script.

Sudo is somewhat of a hotbutton debate among linux/unix admins/users as to whether it's better than root access and what-not. I won't get into that, but sudo does provide minimal protection so that you are allowing access to what you expect to be accessed and not other things (such as opening yourself up to vulnerabilities). Without sudo you would not have know that your call spawns other root-only processes and it's possible that in some cases you don't want those processes to proceed and thus sudo would protect you.

YMMV of course and I just wanted to be the little angel/devil on your shoulder to bear in mind the difference between sudo access and switching to the root user.

Cheers!

BrionS has a valid point about having complete access as root user.........You don't want to accidently type in the infamous 'rm -rf /'.......

But you do have a tiny bit of a safety net with using the 'rootcmd' setup.......You can, and should, always double-check the command you are committing before entering the root password...........Of course, double-checking should be a given anyways, especially when logged in as root, but it's something most of us usually don't bother to do, hence the accidental mishaps you hear about......

With sudo, the same mishaps can occur if you've assigned your user with unlimited access, which is a tendency for some to do, especially on their home box........

Basically, it all boils down to common-sense, such as, do you really need all that power with sudo or can you get by with less and only use root as a last resort for the not so common tasks, or do you really need to do that task with full root privileges using the method I outlined above?......For me, I'm comfortable with my method, and that extra little step of entering the root password makes me a bit more cautious about what I'm doing..........

Of course, not everyone will feel the same as me, and I'm glad BrionS brought up that point.............So, the bottom line, no matter what method you employ is to be absolutely sure of what you're doing before hitting that <Enter> key.........This may seem obvious, especially to the experienced user, but you'd be surprised how many will tend to 'forget' and make mistakes that could have been avoided......As the saying goes. "You have been warned"...

---thegeekster

While reading this I was reminded of times that I accidentally deleted something that was important and started to think about this.
Isn't a file recoverable if the inode(s) of the file in question is known? If so, would it be possible to write a script that runs every
so often that records file names and their inode (s) ? That way if something is deleted there is the possibility of
looking in the file that recorded the information, locating the inode and then going on from there to recover the file? I personally haven't taken
the time yet to try to recover a file this way, but I have read about it briefly in another forum. Just something to think about....

I'd like some input on this and if anyone thinks its possible, I may start digging a little bit and start working on it.

For the ext2 filesystem, recovery is possible, for the reasons you stated..........but journaled filesystems work a bit differently and recovery is not so easy.........about the only way to recover for them is to read the raw sectors and try to piece the files back together.......There may be a few commercial products out that might do a fair job of recovery for the journaled filesystem, but you pay dearly for it.........

PS: Some of the filesystem utilities have some means of basic file recovery, but you need to immediatley stop what you're doing and either umount the partition, if possible, or shut it down and use a rescue disc to do the recovery if the file is in the same partition as the filesystem root directory