I have a number of questions for the community.

1. Do you have any general tips for what to do after installing Slackware?
2. I created an everyday user, but this user doesn't have access to sbin by default, so I have to go root or su to mount drives. Is this the recommended security settings, or should I add the new user to an admin group? If so, which group?
3. In KDE, plugging in an external drive (usually) automatically mounts all the partitions, and they're usable via konqueror. However, in fluxbox, I've so far had to go su, manually create mountpoints and mount the devices. Is there a way to automate this? Also, is it OK to chown a mountpoint to the regular user so I don't have to stay root to do backups?

Hey there!

Enjoy the setup, use it on a daily base...

This is not only normal, but recommended/required behaviour. Dont change that. It is normal, and safe. That way, the user (you, in fact) cannot accidentally mess things up.

Dont know that much about Fluxbox, but should'nt you have dbus in the mix? I suspect this to be started int...rc.conf? In Arch it's this line in xininrc (in the user's home)

Dunnow about Slack, though...

Luck!

Thor

1 members found this post helpful.

Thanks for replying! I found a thread on Slackware and USB storage. I've started hald and messagebus, but I haven't yet downloaded vsupdfstab (I don't have a network card installed yet). That's an old suggestion, and I would hope that in 13.37, this functionality would have made it into the core.

I'll keep poking around.

Would it be advisable to add sbin to the user's PATH, so that something like sudo shutdown -h all would work without having to go su?

You dont need to add whole /sbin to PATH because of using "shutdown" and/or other small software/scripts. You can set /sbin/shutdown to the sudoers-file so you can execute it without password.

You can then put it into the Fluxbox-menu and use the command:
[exec] (Shutdown) {sudo /sbin/shutdown -h now}

1 members found this post helpful.

I've already added jrhorn424 to the sudoers file and to the wheel group, and I've enabled the wheel group in the sudoers file. Shouldn't that take care of it?

I'm not familiar with adding commands to the sudoer file.

Turns out, if I use the thunar file manager instead of konqueror in fluxbox, automounting works within fluxbox. I just had to pick a better file manager.

If you enable wheel-group, then you can basically execute (correct me if I'm wrong) almost everything without a password ( if you enabled the wheelgroup with NOPASSWD). Im not sure if that is a good idea.

The best is to add the /sbin/<program-name> to the sudoers-file. Something like this:

##
## User privilege specification
##
root ALL=(ALL) ALL
expander ALL=(ALL) ALL
expander ALL= NOPASSWD: /sbin/shutdown

1 members found this post helpful.

Hi,

Welcome to LQ!
You should read 13.37 CHANGES_AND_HINTS.TXT.
No need to take steps backward.

Two good references Slackware® Essentials & Slackware® Basics.

Another useful resource would be 'Slackware-Links'. More than just Slackware® links!

You will find the following tutorial useful;
If you want to go multilib then Multilib Slackware for x86_64.

Few more Alien_Bob's links that you will find VERY useful;
This post may seem as a potpourri but just culls from the Sticky, Threads & 'Slackware-Links'.

Happy Slacking!

1 members found this post helpful.

Not quite. The sudoers list allows that user to run commands and programs without a password. Adding names to the sudoers lists does not change the default search path for commands. For non root users the default search path for commands does not include /sbin and /usr/sbin.

I add my primary user to the wheel group and a few commands in the sudoers lists. For about a dozen "administrative" commands I create a sym link in /usr/local/bin to the /usr/sbin command. For example, I have sym links for lspci, lsusb, hdparm, ifconfig, route, runlevel. That way I don't have to meddle with the default search path or type the full path to use those commands.

For other commands that are in the /sbin or /usr/sbin directory, using su to obtain access to those commands is a tad inconvenient. Yet that is the intent with the 'nix multi-user security model.

Bear in mind when a user types the full path to an administrative commmand (/sbin, /usr/sbin), the user then excutes the command. The command itself might impose restrictions on usage, but the user still can run those commands when typing the full path.

1 members found this post helpful.