Archive for the tag 'file'

Including Directives into Web Server Configuration File - Plesk

Note: you can change the location of virtual host directories using the transvhosts.pl utility, which is located either in /usr/local/psa/bin/ or /opt/psa/bin/ directory, depending on your operating system.

You can include domain-specific Apache configuration directives into web server configuration file. In Parallels Plesk Panel, each domain has virtual hosts configuration stored in a separate file httpd.include.

On all Linux systems, this file is located in the directory /var/www/vhosts/domain-name/conf/.

On FreeBSD systems, this file is located in the directory /usr/local/psa/home/vhosts/domain-name/conf/.

To use custom directives or redefine those inserted by Parallels Plesk Panel, you need to create the files vhost.conf or vhost_ssl.conf with necessary directives in the directory /path_to_vhosts/domain-name/conf/ for a domain, and /path_to_vhosts/domain-name/subdomains/subdomain-name/conf/ for a subdomain.

Resource: http://parallels.com/Plesk/

Optimizing the EXT3 file system on Linux

There are some things you can do to give ext3 a boost when you just want speed.

Mount Options noatime,nodiratime

noatime
Do not update inode access times on this file system (e.g, for faster access on the news spool to speed up news servers).

nodiratime
Do not update directory inode access times on this filesystem.

This is one of the quickest and easiest performance gains. This mount option tells the system not to update inode access times. This is a good option for web servers, news servers or other uses with high access file systems

Also from the man pages.

commit=nrsec
Sync all data and metadata every nrsec seconds. The default value is 5 seconds. Zero means default.

#
proc /proc proc defaults 0 0
# / was on /dev/sda1 during installation
UUID=164be035-6571-43b4-820e-cef57b74f1dc / ext3 relatime,noatime,nodiratime,errors=remount-ro 0 1
SBDavid

SUID & SGID File Security

SUID/SGID File Security

SUID/SGID bits can be misused when the SUID/SGID executable has a security hole.

SUID stands for set user id. When a SUID file executed, the process which runs it is granted access to system resources based on the user who owns the file and not the user who created the process. When a file is SUID root it allows a program/script to perform functions that regular users are not allowed to do themselves. Many buffer overflow exploits are the result of SUID programs.

SGID stands for set group id. When looking at files SGID they behave much the same as SUID files, and must be executable for it to have any effect. The SGID bit on a directory means files created in that directory will have their group set to the directory’s group.

When the SUID (set user ID) or SGID (set group ID) bits are set on an executable, it executes with the UID or GID of the owner of the executable rather than that of the person executing it. This means that e.g. all executables that have the SUID bit set and are owned by root are executed with the UID of root. A good example is the passwd command that allows ordinary users to update the password field in the /etc/shadow file which is owned by root.

But SUID/SGID bits can be misused when the SUID/SGID executable has a security hole. Therefore, you might want to search the entire system for SUID/SGID executables and document it.

To search the entire system for SUID or SGID files, you can run the following command:

find / -path /proc -prune -o -type f -perm +6000 -ls

The -prune option in this example is used to skip the /proc filesystem.

For example, to skip the directory `src/emacs’ and all files and directories under it, and print the names of the other files found, do something like this:

find . -path ./src/emacs -prune -o -print

-prune True; if the file is a directory, do not descend into it.

Ensure that code developers don’t set SUID/SGID bits on their programs if it’s not an absolute requirement. Very often you can use workarounds like removing just the executable bit for world/others. However, a better approach is to change the design of the software if possible.

SBDavid

Exporting NFS File Systems

Exporting NFS File Systems

To allow a client access to a filesystem or directory, the /etc/exports serves as the access control list.

To give the network “lan.serverbuddies.com” read-only access to /public_docs, the entries in /etc/exports would look like as follows:

/public_docs *.lan.serverbuddies.com(ro,sync)

Security : It is very important NOT to give write access to NFS clients if not absolutely needed! Entries in /etc/exports are exported read-only (”ro” option) by default.

To allow servers lan1, lan2 and lan3 read-write access to the /backup/setup directory, the entries in /etc/exports would look like as follows:

/backup/setup lan1.serverbuddies.com(rw,sync) lan2.serverbuddies.com(rw,sync) lan3.serverbuddies.com(rw,sync)

Note that options MUST NOT be separated from hostnames or networks with whitespace(s). And use fully qualified domain names to diminish spoofing attempts.

All entries in /etc/exports are exported with the root_squash option (’root squashing’) by default. This means that a root user on a client machine does not have root privileges (root access) to root-owned files on exported NFS filesystems/directories. It is not recommended to turn ‘root squashing” off using the no_root_squash option!

After you’ve made all your entries in /etc/exports, you can export all filesystems/directories using the following command:

# exportfs -a

To unexport all shared filesystems/directories, run:

# exportfs -ua

To see all shared filesystems/directories, run:

# showmount -e localhost

Export list for localhost:

/public_docs *.lan.serverbuddies.com
/backup/setup lan1.serverbuddies.com lan2.serverbuddies.com lan3.serverbuddies.com

Scanning Disks for Volume Groups to Build the Cache File

The vgscan command scans all supported disk devices in the system looking for LVM physical volumes and volume groups. This builds the LVM cache in the /etc/lvm/.cache file, which maintains a listing of current LVM devices.

LVM runs the vgscan command automatically at system startup and at other times during LVM operation, such as when you execute a vgcreate command or when LVM detects an inconsistency. You may need to run the vgscan command manually when you change your hardware configuration, causing new devices to be visible to the system that were not present at system bootup. This may be necessary, for example, when you add new disks to the system on a SAN or hotplug a new disk that has been labeled as a physical volume.

You can define a filter in the lvm.conf file to restrict the scan to avoid specific devices.

SYNOPSIS

/etc/lvm/lvm.conf

DESCRIPTION

lvm.conf is loaded during the initialisation phase of lvm (8). This file can in turn lead to other files being loaded - settings read in later override earlier settings. File timestamps are checked between commands and if any have changed, all the files are reloaded.

Use lvm dumpconfig to check what settings are in use.

# lvm dumpconfig
devices {
dir=”/dev”
scan=”/dev”
preferred_names=[]
filter=”a/.*/”
cache_dir=”/etc/lvm/cache”
cache_file_prefix=”"
write_cache_state=1
sysfs_scan=1
md_component_detection=1
ignore_suspended_devices=0
}

« Prev - Next »