Posts Tagged ‘Linux system’

Multiple users with the same UID/GID

Monday, February 3rd, 2020

First, let me state that this is not a desirable action. It can be done, because, as root, there are so many things which are considered “bad practice” you can still do – this is part of what’s ‘root’ is all about – you know what your system needs, and you know how to do it, even if it’s in a twisted weird way.

In this case, there are two users. One of them is an application user, used by the application administrators, who do not share their password (which is good). The other account is used for file transfers to this directory by an external system which does not support SSH keys. So – the first team won’t share their password (which is fine), the second team needs to place files, and a very complex process of copying the files as the second user, and then chown them to the application user is devised.

A quick solution: Make both users have the same UID and same GID. The result would be that the first user (application user) would have its own password and continue doing whatever it is doing now, while the second user would be able to just drop files where they should be, and they will remain there, with the correct permissions.

A reminder – Linux cares little for user names. They are used in many reverse and forward translations, however, on filesystem, the user ID and group ID (UID and GID, in that order) are what matters. The file’s metadata includes the number, not the name.

A simple solution would be to create the user with ‘useradd’ and the flag ‘-o’ which means “non-unique”. This is very simple to do, and would pose no problem.

However, the application users might see, when running ‘ls’ commands, that the files belong to the other, transfer, user, and vice versa. This is caused not by the current login information, but due to the local NSCD caches in use. In particular – ‘nscd’ – the Name Service Caching Daemon.

So – we would strive to have both users see their own “name” when listing files, because otherwise, it will create some user unrest, which we strive to avoid.

The trick is to disable caching, by editing the file /etc/nscd.conf with these values:

enable-cache passwd no
persistent passwd no

Following that, restart the ‘nscd.service’ on your system, and your users should see their “own” name when listing files.

Hot adding Qlogic LUNs – the new method

Friday, August 8th, 2008

I have demonstrated how to hot-add LUNs to a Linux system with Qlogic HBA. This has become irrelevant with the newer method, available for RHEL4 Update 3 and above.

The new method is as follow:

1
2
echo 1 > /sys/class/fc_host/host<ID>/issue_lip
echo "- - -" > /sys/class/scsi_host/host<ID>/scan<

Replace “<ID>” with your relevant HBA ID.

Notice – due to the blog formatting, the 2nd line might appear incorrect – these are three dashes, and not some Unicode specialy formatted dash.

Graphing on-demand Linux system performance parameters

Tuesday, May 20th, 2008

Current servers are way more powerful than we could have imagined before. With quad-core CPUs, even the simple dual-socket servers contain lots of horse-power. Remember our attitude towards CPU power five years ago, and see that we’re way beyond our needs.

When modern servers are equipped with at least eight cores, other, non-CPU related issues become noticeable. Storage, as always, remains a common bottleneck, and, as an increase in expectations always accommodate increase in abilities, memory and other elements can be the cause for performance degradation.

sar‘ is a known tool for Linux and other Unix flavors, however, understanding the contexts within is not trivial, and while the data is there, figuring what is relevant for the issue at hand becomes, with more disk devices, and more CPUs, even more complicated.

kSar is a simple java utility which makes this whole mess into a simple, readable graphs, capable of being exported to PDF for the pleasure of the customers (where applicable). It parses existing sar files, or the extracted contents of ‘sa’ files (from, by default, /var/log/sa/). It is a useful tool, and I recommend it with all my heart.

Alas, when it comes to parsing ‘sa’ files, you will need, in most cases, either to export the file into text on the source machine, or use a similar version of sysstat tools, as changes in versions reflect changes in the binary format used by sar.

You can obtain the sysstat utils from here, and compile it for your needs. You will need only ‘sar’ on your own machine.

An important note – you will not be able to compile sysstat utils using GCC 4.x. Only 3.x will do it. The error would look like:

warning: ‘packed’ attribute ignored for field of type `unsigned char…

followed by compilation errors. Using GCC version 3.x will work just fine.

DSL (Damn Small Linux) Diskless boot

Friday, August 31st, 2007

I have come across a requirement to boot a thin client on a very cheap hardware into Linux. Due to the tight hardware requirements, and the tight budget, I have decided to focus on diskless systems, which can be easily modified and purchased to our needs.

Not only that, but due to the hardware configuration (Via 333MHz, 128MB RAM, etc) I have decided to focus on a miniature Linux system.

I dislike re-doing what someone else has done, unless I can do it noticeably better. I have decided to use DSL (Damn Small Linux) as my system of choice, with only minor changes to fit my needs:

Out of the “box”, I was unable to find network-boot DSL. Quickly searching their site, the version which seemed to fit was the initrd-only system. I downloaded it from this mirror, but you can find it as the dsl-x.x.x-initrd.iso file.

Extracting the initrd from the ISO file is quite simple:

mkdir /mnt/iso
mount -o loop dsl-x.x.x-initrd.iso /mnt/iso

And from here you can just copy the contents of the directory /mnt/iso/boot/isolinux/ selectively to your tftpboot directory.

So I got 50MB initrd which worked just fine. Changing this was quite a procedure, because in addition to the steps per the wiki hacking guide, I was required to extract the KNOPPIX file outside of the initrd, and repackage it when done. Quite messy, however, stand-alone as soon as the system has been able to boot.

An alternate I have decided to investigate into was of booting into nfs mount, aka, accessing the KNOPPIX iso disk through NFS and not through CDROM.

I was able to find some leads in DSL forums at this page, which lead to this guide. I was able to download pxe boot image from Knoppix themselves, however, it was based on an old kernel (2.4.20-XFS) which was part of Knoppix 3.3 (cannot find it anymore) and although reached the level of actually booting my nfs, didn’t include enough network drivers (I wanted pcnet32 to be able to “play” with VMware for the task), and was incompatible with my existing DSL.

I had opened the supplied Knoppix initrd, and replaced the modules version to the one supplied with DSL – 2.4.24, per the rest of the system. In addition, I have added my required modules, etc, and was able to boot successfully both on VMware and on the thin client hardware.

To replace the modules, one needs to follow these general-only guidelines (these are not exactly step-by-step instructions):

Mount through loop the DSL KNOPPIX image, for example, in /mnt/dsl
Uncompress the Knoppix PXE initrd
Mount through loop the uncompressed Knoppix PXE initrd, for example, in /mnt/initrd
cd to /mnt/initrd/modules
Replace all modules in the current tree with the ones supplied by DSL, obtainable from /mnt/dsl/lib/modules/2.4.26 directory tree, including the cloop.o module
Umount the initrd image
Compress the initrd image
Boot using DSL linux and the new initrd image.

In order to boot successfully, you need to supply the pxe boot these two instructions:

nfsdir=nfs-server:/path/to/KNOPPIX directory

(since I was quite unsure about the letter case required, I have created a symlink from lower-case to upper case, so I had a link /mnt/KNOPPIX to a directory /mnt/knoppix, and inside this directory, a file called knoppix and a symbolic link to this file KNOPPIX. In my case, the exported path was /mnt/ only. Notice this one!).

BOOT_IMAGE=KNOPPIX – but you can have different KNOPPIX images for different purposes.

Finally it has worked correctly. Changes can be done only to the KNOPPIX iso image, per the hacking guide.

This is my PXE-enabled initrd, based on the text above, which fits DSL-3.4.1: minirt24.gz

DL140 Generation 1 (G1) and LILO do not work

Wednesday, February 14th, 2007

I add to this blog all pieces of information which I might think could help other people.

One of the things I have encountered short while ago had to do with DL140 G1 system cannot boot Linux.

It’s Linux system (RedHat 4 32bit) was deployed by an external system and the system could not boot. However, when installed from CD, the system booted just fine. The symptom for this was that after booting, the screen showed:

LILO: Loading Linux…..

and that’s all. The system could have booted (and did so once) after several days, however, this is not really a desired status.

It seems to be an issue of Lilo and this specific hardware. Other systems (non DL140) were able to boot just fine using Lilo, and this same kernel version was bootable on that system through other means.

Replacing Lilo with GRUB during installation/deployment solved the isse. FYI.