CRUX : Home

Home :: Documentation :: Download :: Development :: Community :: Wiki :: Ports :: Bugs :: Links :: About

Back to wiki start page

other FAQ sections ...

Categories: Faq

FAQ - Configuration

Table of contents

1. How do I get sshd running?

First ensure that there are no firewall rules rejecting inbound traffic to the port designated in /etc/ssh/sshd_config (Port 22 by default). The default nftables configuration already allows traffic on port 22, so unless you edited the file /etc/nftables.nft, activated a different firewall, or instructed sshd to listen on a non-standard port, a running ssh daemon should be reachable from hosts in your network. You can then start sshd manually by entering the command /etc/rc.d/sshd start. For automatic loading of sshd when CRUX starts up, simply add sshd to the SERVICES array of /etc/rc.conf, i.e. SERVICES=(... sshd ...).

2. Why is my newly-created regular user not allowed to run crontab?

The core port dcron installs /usr/bin/crontab with permissions rwsr-x---, owner=root, and group=users, but CRUX 3.7 now ships with a useradd configuration that does not automatically put new accounts into the 'users' group.

The old behaviour of useradd (prior to December 2020) resulted from a historical accident: the fallback gid chosen by useradd happened to be the same as the gid (100) that traditionally appears on the users line of /etc/group. The administrator of a machine running CRUX 3.6 or earlier can be forgiven for inferring a deliberate design decision, but changes to the upstream useradd source shattered the illusion of such intentionality. Now in the absence of any overriding directives (in /etc/defaults/useradd or /etc/login.defs or on the command-line), useradd will assign gid 1000 to any new account.

One such overriding directive is the line USERGROUPS_ENAB yes, which now appears in the file /etc/login.defs installed by the shadow port. This directive prevents useradd from falling back on its hard-coded default gid, 1000, and instead allows it to select an unused gid to be associated with a new group of the same name as the newly-added user. A cosmetically appealing side-effect is that useradd never assigns a gid that has no corresponding entry in /etc/group. Separate primary groups for each user also makes it harder to accidentally allow your files to be clobbered by someone else in the 'users' group, unless your login profile sets a dangerously permissive umask.

The old behaviour — assigning 'users' as the primary group — is out of sync with the recommended practices these days, but if you want it, the three easiest options are: a wrapper script, an alias, or remembering to type -g users with every invocation of useradd.

If you upgraded from an installation of CRUX 3.6 or earlier, then your existing users and groups will still have their 3-digit UIDs and GIDs, with nearly every non-system account in the 'users' group. To avoid a confusing mix of old GIDs and new GIDs, you can use the upgrade as an opportunity to start afresh: create new CRUX 3.7 users that have separate primary GIDs, and transfer the home directories of the old users to the ${HOME}s of their CRUX 3.7 counterparts.