Author: Admin

Port forwarding using xinetd.

An easy method to do port forwarding without the iptables is to use the xinetd.
In order to port forward with xinetd, you will need to create a configuration file:

root# vim /etc/xinetd.d/imap_forward

For example: Forward port 143 on localhost to remote server on port 143:

service imap_forward
{
disable = no
type = UNLISTED
socket_type = stream
protocol = tcp
user = nobody
wait = no
redirect = remote_IP_or_server_name 143
port = 143
}

The three load-average values in the first line of top output are:

The three load-average values in the first line of top output are the 1-minute, 5-minute and 15-minute average. (These values also are displayed by other commands, such as uptime, not only top.) That means, reading from left to right, one can examine the aging trend and/or duration of the particular system state. The state in question is CPU load—not to be confused with CPU percentage. In fact, it is precisely the CPU load that is measured, because load averages do not include any processes or threads waiting on I/O, networking, databases or anything else not demanding the CPU. It narrowly focuses on what is actively demanding CPU time. This differs greatly from the CPU percentage. The CPU percentage is the amount of a time interval (that is, the sampling interval) that the system’s processes were found to be active on the CPU. If top reports that your program is taking 45% CPU, 45% of the samples taken by top found your process active on the CPU. The rest of the time your application was in a wait. (It is important to remember that a CPU is a discrete state machine. It really can be at only 100%, executing an instruction, or at 0%, waiting for something to do. There is no such thing as using 45% of a CPU. The CPU percentage is a function of time.) However, it is likely that your application’s rest periods include waiting to be dispatched on a CPU and not on external devices. That part of the wait percentage is then very relevant to understanding your overall CPU usage pattern.

Kernel – Install and Compile in Debian Linux

To get started, we are going to need some packages, namely fakeroot and kernel-package:

root# apt-get install fakeroot kernel-package

Now, lets take a latest source tarball from www.kernel.org or you may use following wget command to download it.

root# wget -c https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.2.58.tar.xz

Now, let’s unpack the archive.

root# tar -xvJf linux-3.2.58.tar.xz

After, extracting, a new kernel source directory will be created.

root# cd linux-3.2.58

Now, we will want to configure the kernel. It is best to start with a configuration that you are currently using and work from there. To do this, we will copy the current configuration from the /boot directory to the current working directory and save it as .config.

root# cp /boot/config-3.2.0-4-amd64 ./.config

Now we can configure the kernel:

root# make menuconfig

Once that is done, it is time to clean the source tree.

root# make-kpkg clean

Finally, it’s time to build the kernel package.

root# export CONCURRENCY_LEVEL=3
root# fakeroot make-kpkg --append-to-version "-customkernelname" --revision "1" --initrd kernel_image kernel_headers

"Cannot access path" error when mounting an NCP share from OES11 SP1 using ncpmount.

When trying to mount an NCP share with the ncpmount command, the system prints out the following error:

Cannot access path "{volume-name}": Invalid argument

A network trace reveals a problem in the name space negotiation between the server and client. Even though the OES11 SP1 NCP server advertises the NFS namespace with the volume to be mounted, it returns error 191 (ERR_INVALID_NAMESPACE) when the NFS name space is used in requests for accessing the given volume.

ncpmount -S 192.168.87.70 -A 192.168.87.70 -o tcp,nonfs -V VOLC1 -U admin.novell /mnt

How to Identify Your Linux File System Type.

To identify a Linux file system you can use the following standard command:
df -T or cat /etc/fstab or mount but the commands listed below are much more cool:

Use the file command.

root# file -sL /dev/sdc1
/dev/sdc1: sticky Linux rev 1.0 ext3 filesystem data, UUID=28d01367-3886-4f67-a3c9-447bf006ae27 (needs journal recovery) (errors) (large files)

root# file -sL /dev/sdc1
/dev/sdc1: sticky Linux rev 1.0 ext3 filesystem data, UUID=28d01367-3886-4f67-a3c9-447bf006ae27 (needs journal recovery) (errors) (large files)

Use the fsck command:

root# fsck -N /dev/sdc1
fsck from util-linux 2.20.1
[/sbin/fsck.ext3 (1) -- /mnt/data] fsck.ext3 /dev/sdc1

root# fsck -N /dev/zeus/root
fsck from util-linux 2.20.1
[/sbin/fsck.ext4 (1) -- /] fsck.ext4 /dev/mapper/zeus-root

How do I shrink the root logical volume (LV) on LVM?

The root partition and LV resizing should be done on unmounted partitions, so you have to boot from a rescue CD or USB stick, run it as live CD. Then make sure, that your root LV is not installed, by

mount

and unmount it when necessary. The LVM command vgchange changes attributes of volume groups. What needs to be “changed” to access the volume is the “availability” — i.e. to make the kernel realize the LVM volumes are there. This can be done by the command:

lvm vgchange -a y

Note, in rescue mode the system command is lvm and the LVM command that is run is vgchange. The -a y argument sets the availability to “y” or yes. As there are no specified LVM volume groups, this command will make all LVM volumes found available to the rescue kernel.

Once the kernel is aware of all LVM volumes they will be automatically mapped as devices. These are usually located under /dev/VolGroup or /dev/mapper/VolGroup (where “VolGroup” is the name of the Volume Group). Then do filesystem check

e2fsck -f /dev/yourVG/yourLV

on this LV. Then shrink filesystem

resize2fs /dev/yourVG/yourLV 5G

and reduce LV

lvreduce -L 5G /dev/yourVG/yourLV

Reboot to your system, Enjoy!

Tomcat6 – SLES11sp3 – "This account is currently not available."

The problem is located in the initscript (/etc/rc.d/init.d/tomcat6) with the invocation of the $SU command, which is either /sbin/runuser or /bin/su. Please note there are multiple places in the initscript where $SU is invoked, here is one typical example.

$SU – $TOMCAT_USER -c “${TOMCAT_SCRIPT} start” >> $TOMCAT_LOG 2>&1

The key element here to notice is that a command line is being passed via the -c argument, this requires the user ($TOMCAT_USER) to have a shell in which to execute the -c command. But system daemons shouldn’t have login shells for security reasons. If $TOMCAT_USER doesn’t have a login shell then $SU aborts with the message:

“This account is currently not available.”

The solution is to provide a temporary shell to $SU for the purpose of executing the -c command. This can be done with the -s arg to $SU. One possible solution would be to modify the definition of $SU in the script, thus:

# For SELinux we need to use 'runuser' not 'su'
if [ -x "/sbin/runuser" ]; then
SU="/sbin/runuser"
else
SU="/bin/su"
fi

would become:

if [ -x "/sbin/runuser" ]; then
SU="/sbin/runuser -s /bin/sh"
else
SU="/bin/su -s /bin/sh"
fi