Sometimes and with some DB platforms especially when you are testing and want to reduce the number of variables during development, testing etc.. you don not want SELinux watching your back. While it is a must to enable SELinux in hardened production systems it can be quite a pain to handle. Sometimes it needs disabling (if for a short period), Here is how.
# Important
Changes you make to files while SELinux is disabled may give them an unexpected security label, and new files will not have a label. You may need to relabel part or all of the file system after re-enabling SELinux.
Command Line
From the command line, you can edit the /etc/sysconfig/selinux file. This file is a symlink to/etc/selinux/config. The configuration file is self-explanatory. Changing the value of SELINUX orSELINUXTYPE changes the state of SELinux and the name of the policy to be used the next time the system boots.
[root@host2a ~]# cat /etc/sysconfig/selinux
# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
# enforcing - SELinux security policy is enforced.
# permissive - SELinux prints warnings instead of enforcing.
# disabled - SELinux is fully disabled.
SELINUX=permissive
# SELINUXTYPE= type of policy in use. Possible values are:
# targeted - Only targeted network daemons are protected.
# strict - Full SELinux protection.
SELINUXTYPE=targeted
# SETLOCALDEFS= Check local definition changes
SETLOCALDEFS=0
At the prompt type :
echo 0 > /selinux/enforce
From the GUI
Use the following procedure to change the mode of SELinux using the GUI.
# Note
You need administrator privileges to perform this procedure.
On the System menu, point to Administration and then click Security Level and Firewall to display the Security Level Configuration dialog box.
Click the SELinux tab.
In the SELinux Setting select either Disabled, Enforcing or Permissive, and then click OK.
If you changed from Enabled to Disabled or vice versa, you need to restart the machine for the change to take effect.
# Note
Changes made using this dialog box are immediately reflected in /etc/sysconfig/selinux.
Total-addresses: how many unique addresses can be represented. To determine how many are available to be assigned to devices you need to subtract 2 from the provided number to allow for the ‘network’ and ‘broadcast’ address. A further one of these may need to be assigned to a router.
Net bits
Subnet mask
Total-addresses
/20
255.255.240.0
4096
/21
255.255.248.0
2048
/22
255.255.252.0
1024
/23
255.255.254.0
512
/24
255.255.255.0
256
/25
255.255.255.128
128
/26
255.255.255.192
64
/27
255.255.255.224
32
/28
255.255.255.240
16
/29
255.255.255.248
8
/30
255.255.255.252
4
eg: 192.168.1.0/25 would include all address between 192.168.1.0 and 192.168.1.127.
eg: 192.168.1.128/25 would include all address between 192.168.1.128 and 192.168.1.255
Unix / Linux has a great inbuilt simplicity to it where you can create file systems on any block set . Now .. a file is a block set so technically and truly at it’s core a file system can be built on a file and mounted :
I need a 100MB partition for some tests :
Using ofcourse Google as my calculator {pfsssst !!! obviously .. DUH}. I tried 100MB / 512 bytes and got
(100 megabytes) / (512 bytes) = 204 800
[root@localhost admin]# dd if=/dev/zero of=disk-image count=204800
204800+0 records in
204800+0 records out
104857600 bytes (105 MB) copied, 41.8633 s, 2.5 MB/s
[root@localhost admin]#
This command leaves me with a 105MB file in which to create my etx3 fs like so :
Once this file is created I will use the mkfs to format over the disk-image file:
[root@localhost admin]# /sbin/mkfs -t ext3 -q disk-image
disk-image is not a block special device.
Proceed anyway? (y,n) y
[root@localhost admin]#
Thus a filesystem now resides on my file named disk-image.
We can now use a loopback device to mount the disk-image anywhere we need it:
[root@localhost admin]# mkdir /mnt/test1
[root@localhost admin]# mount
/dev/sda2 on / type ext4 (rw)
proc on /proc type proc (rw)
sysfs on /sys type sysfs (rw)
devpts on /dev/pts type devpts (rw,gid=5,mode=620)
tmpfs on /dev/shm type tmpfs (rw,rootcontext="system_u:object_r:tmpfs_t:s0")
/dev/sda1 on /boot type ext4 (rw)
none on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
[root@localhost admin]# mount disk-image /mnt/test1/
mount: /home/admin/disk-image is not a block device (maybe try `-o loop'?)
[root@localhost admin]# mount -o loop disk-image /mnt/test1/
[root@localhost admin]# cd /mnt/test1/
[root@localhost test1]# ls
lost+found
[root@localhost test1]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 18G 2.7G 14G 16% /
tmpfs 504M 768K 503M 1% /dev/shm
/dev/sda1 291M 50M 226M 19% /boot
/home/admin/disk-image
97M 5.6M 87M 7% /mnt/test1
[root@localhost test1]# touch file1
[root@localhost test1]# mkdir -p top1/bottom1
[root@localhost test1]# tree
.
+-- file1
+-- lost+found
+-- top1
+-- bottom1
3 directories, 1 file
[root@localhost test1]#
Thus a new file system is now running inside the file.
Backing up that file or moving it to another system would entail now quiescing any applications/scripts working with the file, unmounting the loopback fs system, doing your thing then replace all the cards on the deck 🙂
Ubuntu — and all Debian-based distros — includes the Advanced Packaging Tool (APT), which can be used to easily download and install software for the operating system. This article looks at APT, and how it is used.
Yum is a tool for automating package maintenance for a network of workstations running any operating system that use the Red Hat Package Management (RPM) system for distributing packaged tools and applications. It is derived from yup, an automated package updater originally developed for Yellowdog Linux, hence its name: yum is “Yellowdog Updater, Modified”.
Yup was originally written and maintained by Dan Burcaw, Bryan Stillwell, Stephen Edie, and Troy Bengegerdes of Yellowdog Linux (an RPM-based Linux distribution that runs on Apple Macintoshes of various generation). Yum was originally written by Seth Vidal and Michael Stenner, both at Duke University at the time. Since then both Michael and Seth have moved on, Seth to working for Red Hat, where he remains the dominant force behind yum development and maintenance.
It is important to note that yum is an open source GPL project and that many people have contributed code, ideas, bug fixes and documentation. The AUTHORS list was up to 26 or so as of the time of this HOWTO snapshot; yum is a clear example of the power of open source develpmment!
Yum is a Gnu Public License (GPL) tool; it is freely available and can be used, modified, or redistributed without any fee or royalty provided that the terms of its associated license are followed.
In Linux installing software can be done in more than one way. Software installed on a platform is always reccommended to be installed from the repositories using the yumor apt tools. These tools have a lot of logic in them to check for package consistency, resolve dependencies , compare local version to the one being installed, etc.
Yum and Apt will be discussed in other pages but suffice it to say they are the tools you must use (depending on your platform one will be preferred to the other. e.g. the rpm systems usually based on Red Hat redistributions called downstream distros use yum and Debian based distributions use apt as the preferred package manager subsystem.
There are occasions, rare on the average, but the more advanced the setup you are trying to deploy the more common this becomes, when you need to compile a later version from what your repository has. Now this is not a good practise according to stability buffs but it is a necessary one if you are going after security. This because repositories are compiled (or should be) with a certain amount of testing before a version is updated hence there is a natural lag behind the latest stable versions of any one given package. This especially true for packages that are heavily updated (usually due to security updates and bug fixes).
As always the two most important and valid reasons for running versions later than those in the repositories are :
Security : a vulnerability becomes known that might compromise thsecurity of the service or system, and there has been a fix that has been tested.
Features: new features are required that the older version in the repo does not support or was still in beta and has now been promoted to production ready.
The /etc/passwd file stores essential information, which is required during login i.e. user account information. /etc/passwd is a text file, that contains a list of the system’s accounts, giving for each account some useful information like user ID, group ID, home directory, shell, etc. It should have general read permission as many utilities, like lsuse it to map user IDs to user names, but write access only for the superuser (root).
The anatomy of /etc/passwd
The /etc/passwd contains one entry per line (row) for each user (or user account) of the system. All fields are separated by a colon (:) symbol. Total seven fields as follows. It is one of the many database text files in NIX systems. Generally, passwd file entry looks as follows :
A sample row from the /etc/passwd file
Username: It is used when user logs in. It should be between 1 and 32 characters in length.
Password: An x character indicates that encrypted password is stored in /etc/shadow file.
User ID (UID): Each user must be assigned a user ID (UID). UID 0 (zero) is reserved for root and UIDs 1-99 are reserved for other predefined accounts. Further UID 100-999 are reserved by system for administrative and system accounts/groups.
Group ID (GID): The primary group ID (stored in /etc/group file)
User ID Info: The comment field. It allow you to add extra information about the users such as user’s full name, phone number etc. This field use by finger command.
Home directory: The absolute path to the directory the user will be in when they log in. If this directory does not exists then users directory becomes /
Command/shell: The absolute path of a command or shell (/bin/bash). Typically, this is a shell. Please note that it does not have to be a shell.
Viewing User List
/etc/passwdis only used for local users only. To see list of all users, enter:
$ less /etc/passwd
To search for a username called toro, enter:
$ grep toro /etc/passwd
/etc/passwd file permissions
The permissions on the /etc/passwd file should be read only to all users i.e. 644 (-rw-r–r–) and the owner must be root: $ ls -l /etc/passwdOutput:
One can read the /etc/passwdfile using the while loop and IFS separator as follows:
#!/bin/bash
# seven fields from /etc/passwd stored in $f1,f2...,$f7
#
while IFS=: read -r f1 f2 f3 f4 f5 f6 f7
do
echo "User $f1 use $f7 shell and stores files in $f6 directory."
done < /etc/passwd
Another way to list all entries in the passwd database is using the getentutility. This will show all user accounts, regardless of the type of name service used. For example, if both local and LDAP name service are used for user accounts, the results will include all local and LDAP users:
$ getent passwd
The /etc/shadow file
Passwords are not stored in /etc/passwd file the. It is stored in /etc/shadow file. In the good old days there was no great problem with this general read permission. Everybody could read the encrypted passwords, but the hardware was too slow to crack a well-chosen password, and moreover, the basic assumption used to be that of a friendly user-community, both assumptions really wrong today. Almost, all modern Linux / UNIX line operating systems use the shadow password suite, where /etc/passwd has asterisks (*) instead of encrypted passwords, and the encrypted passwords are in /etc/shadow which is readable only by the superuser.
EPEL(Extra Packages for Enterprise Linux) is a repository of (as the name implies) A collection of packages not directly released with the given linux distribution release cycle. By default these packages are not available but all the wiring in the amazon AMI instance is already done all one needs to do is enable it. To do so check the two following ways.
Modify /etc/yum.repos.d/epel.repo.
Under the section marked [epel], change enabled=0 to enabled=1.
To temporarily enable the EPEL 6 repository, use the yum enablerpo option :
We all had the problem of needing to backup a folder or an entire system from a machine before decommissioning or as a postfix backup solution only to find tarring aint gonna work cause you have very little space left. Also there are folders you want to avoid tarring since they contain logs or system virtual folders that you want to skip.
So you need to get a tar from a machine have very little space left and you need to pull all the files in a compressed fashion; the following command calls a backup as root through ssh using tar on the source machine and skips the folders you do not want :
The result of the above command is a backup of the / compressed at source piped through console through ssh back to your local / backup repo machine in .tar.gz format leaving out the rubbish thanks to the :