How to extract web files, databases etc from Plesk backup manually?
If you have not so big dump file, for example 100-200MB, you can unzip it and open in any local Email client. Paths of the dump will be shown as attachments. Choose and save needed one then unzip it.
Other Way - It can be done using mpack tools to work with MIME files. This packet is included into Debian:
For other Linux systems you can try to use RPM from ALT Linux:
ftp://ftp.pbone.net/mirror/ftp.altlinux.ru/pub/distributions/ALTLinux/Sisyphus/files/i586/RPMS/mpack-1.6-alt1.i586.rpm
or compile mpack from the sources: http://ftp.andrew.cmu.edu/pub/mpack/.
- Create an empty directory to extract the back up file:
# mkdir recover
# cd recover
and copy backup into it.By default Plesk backup is gzipped (if not, use cat), so run zcat to pass data to munpack to extract content of directories from the backup file:
# zcat DUMP_FILE.gz > DUMP_FILE
# cat DUMP_FILE | munpack
In result you get the set of tar and sql files that contain domains’ directories and databases. Untar the needed directory. For example if you need to restore the httpdocs folder for the DOMAIN.TLD domain:
# tar xvf DOMAIN.TLD.htdocs
Reference: http://parallels.com/
How to protect one Yum repo’s packages from being replaced by packages from another source?
If we use two different repositories, each holding a different version of the same package, only the latest of the two will be installed if you use yum to update that package. This can lead to problems if the third party repository contains a newer version of a core system package than the Red Hat repository.
The yum-protectbase plugin will protect files of the base repository from being replaced by packages from a third party repository.
To install the plugin, use this command:
yum install yum-protectbase
This will install the plugin and its basic configuration file, /etc/yum/pluginconf.d/protectbase.conf
Setting are stored under /etc/yum/pluginconf.d/rhnplugin.conf with a section name matching the repo.id of the channel. You need to add :
To protect a different repository, go to its configuration file in /etc/yum.repos.d/repository.repo and add this line to its configuration
/etc/yum.repos.d/repository.repo
Add
[repository]
…
protect = 1
You will need to add this for each repository which needs to be protected.
Email notification everytime users run “sudo” on Linux
For Redhat, Centos Systems make sure that sendmail is running on the machine and configured to send out emails.
Run
Add the following configuration in /etc/sudoers
visudo parses the sudoers file after the edit and will not save the changes if there is a syntax error.
Defaults mail_always
Defaults mailerpath=/usr/sbin/sendmail
Defaults mailto=”root@serverbuddies.com”
Defaults mailsub=”*** Command run via sudo on %h ***”
Defaults mailerflags=”-t”
How do I restrict the use of su command?
The su command is used to become another user during a login session. Invoked without a username, su defaults to becoming the superuser. The optional argument - may be used to provide an environment similar to what the user would expect had the user logged in directly.
You can SSH using a regular user account, then use the su command to obtain root access. This is true for any user that enters the su command and enters the root password. Root access means absolute access, thus, it is recommended that you limit the usernames that can use the su command and get root access.
We have a group called ‘wheel’ on the Linux system that we can utilize for this a special purpose. We can add usernames that you want to have su access to become a member of the wheel group and then restrict su so that only the members of the wheel group can use the su command.
Add a user with the id buddy to the wheel group:
Now we need to go to the directory /etc/pam.d
/etc/pam.d$ ls -l su
-rw-r–r– 1 root root 2303 May 26 19:53 su
Edit the PAM configuration file for su, /etc/pam.d/su, in a text editor and remove the comment (#) from the line shown below:
# auth required /lib/security/pam_wheel.so use_uid
So that is looks like this:
auth required /lib/security/pam_wheel.so use_uid
Doing this will permit only members of the group wheel to use the su command.
Below is the debian configuration file:
# The PAM configuration file for the Shadow `su’ service
#
# This allows root to su without passwords (normal operation)
auth sufficient pam_rootok.so
# Uncomment this to force users to be a member of group root
# before they can use `su’. You can also add “group=foo”
# to the end of this line if you want to use a group other
# than the default “root” (but this may have side effect of
# denying “root” user, unless she’s a member of “foo” or explicitly
# permitted earlier by e.g. “sufficient pam_rootok.so”).
# (Replaces the `SU_WHEEL_ONLY’ option from login.defs)
auth required pam_wheel.so
Disabling SSH Login for root user
Below are instructions for disabling the root user and allowing another user to assume the root users permissions. This adds another layer of security because an additional username and password must now be entered before gaining the root user privileges.
Before you disable root logins you should add an administrative user that can ssh into the server and become root with su.
In the following example we are using buddy for the username, but can be replaced with any username you wish to use.
root@dell:~# useradd buddy
root@dell:~# id buddy
uid=1005(buddy) gid=1007(buddy) groups=1007(buddy)
Set the password for the buddy user. When prompted type and then retype the password.
root@dell:~# passwd buddy
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
SSH to the server with the new admin user and ensure that the login works.
Verify that you can su (switch user) to root with the admin user.
buddy@dell:/$ su
Password:
root@dell:/# whoami
root
Edit /etc/ssh/sshd_config with your favorite text editor.
Change this line:
to this:
Ensure that you are logged into the box with another shell before restarting sshd to avoid locking yourself out of the server.
# /etc/init.d/sshd restart
