Version 1.35.1
Released: 2010-02-16
Convert binaries to variables new
usermod=/usr/sbin/usermod
useradd=/usr/sbin/useradd
userdel=/usr/sbin/userdel
groupmod=/usr/sbin/groupmod
groupadd=/usr/sbin/groupadd
groupdel=/usr/sbin/groupdel
passwd=/usr/bin/passwd
chpass=/usr/bin/chpass
chpasswd=/usr/sbin/chpasswd
edquota=/usr/sbin/edquota
setquota=/usr/sbin/setquota
repquota=/usr/sbin/repquota
pw=/usr/sbin/pw
add variables to directadmin.conf.
Values will be internal defaults. They will not physically be present in the directadmin.conf unless you add them. Note that all of the binaries span multiple OS's. Your OS will not use all of them, so don't worry if you don't see all of these binaries on your system.
Pre-backup check for hardlinks to resolve backup errors fixed
2 new options in the directadmin.conf:
backup_hard_link_check=1
default to 1. Before all account backups are created by DA, a check will be done on the User's backup path. For any hard link found, DA will notify all Admins on the box, even if the backup is being created by the end-User. As well, the creation of that backup file will be aborted. With this option enabled, no User backup tar.gz will be created if DA finds a hard link. If you're not farmiliar with what a hard link is, it's a duplicate of a file on disk, but only duplicates the node information. It doesn't duplicate the file itself. This means that any changes to the file's contents will cause the data from both files to change, since they both point to the same data on disk. This reason this check is relevant is for when Users create a hard link to sensitive files on disk, like /etc/shadow. This is not allowed, hence that User will not be backed up if there are any hard links in his path. Note that hard links are different from symbolic links. Symbolic links are not an issue since tar only adds the symbolic link itself, not the file it points to.
If you find that this check increases the load of your system too much when backups are created, and you feel that your system will not be affected by hard-links (you trust all of your Users), then this check can be disabled, but do so cautiously. It's recommended to leave it on.
strict_backup_permissions=0
default to 0. Enabling this option will run tar as user:apache. This is more secure, but is much more likely to run into permission errors when creating backups. Directories that are chmod to 0, or not readable by either user or apache will throw errors. With the default value of 0, the backup creation will not run into permission problems, since it will use a higher level user access to create those backups. This is why the pre-backup check is important, to make the use of this higher level safer. Note, that after testing, it has been found that with tar running as group apache, the files and directories need to have group read access permission (g+r) on them. This means a minimum of 640 if the file is apache:apache. This discovery somewhat voids the use of apache as the group, but will offer more flexibility for admins if they wish to use this method. For most people, using the default value of 0 will be preferred.
Note: This change removes the post-update check that DA does to scan all User folders for read access. Running the command:
echo "action=syscheck" >> /usr/local/directadmin/data/task.queue
will no longer scan User's folders for readability or hard links.
The pre-backup check will take care of the hard-links.