Ram Kumar's questions

We are in the early stages of standardizing our infra. As an immediate step, we want to restrict users from manipulating the history. Have setup some restrictions for the same. But recently found that there are couple of loop holes.

• Users can remove the history entry by just running 'history -d '
• 'set +o history' will stop the history file from being updated.

I am finding ways to restrict users from running this command. I can't think of a way out for this.

Any suggestions will be helpful. Please let me know if something isn't clear. Thanks.

We are using CentOS and our shell is bash

-Ram Kumar

We recently purchased a Dell R640 with Perc H740P Mini (Embedded) RAID controller. There are two 500GB SAS disks in RAID 1.

When we tried to install CentOS7.2 (via cdrom) from our custom image, we got the below error as it was not able to detect the hard disks.

And from this link (https://www.centos.org/forums/viewtopic.php?t=64039), we found that it could be an issue with CentOS 7.2 and it's fixed in CentOS 7.4.

So, I downloaded CentOS 7.4 and when I tried to install it, its giving me the below error. FWIW, the same iso image is working fine on a virtual machine.

I looked around but couldn't find anything amiss. I did try re-creating the virtual drive/running hardware diagnostics but nothing helped. PERC firmware is up to date.

Any pointers will be helpful.

Let me know if you have any queries, thanks.

I am working on setting up a PXE based build system in our environment.

Short description on how it will work is, server will boot into network, get an IP address and PXE server details from DHCP server and then we select the rebuild option in the PXE menu. Then, it should download the kickstart file over http. Here is the problem, I noticed that in my couple of test servers this step is failing as it cannot download the Kickstart file.

Few additional points:

There is no problem with the HTTP server as there is another server which is getting rebuilt successfully (in the same setup). And even the problematic servers used to work fine before and it stopped working all of a sudden. I am able to download the kickstart file using wget.

I tried looking around but couldn't find anything amiss. Out of my three test servers, two of them are Dell PowerEdge R710 and the third one is a desktop. All three used to work fine but since last few days, one Dell PowerEdge server and the desktop started having this issue. Attached a screenshot on how its trying to download the kickstart file. For troubleshooting, I tried changing 'inst.ks' to 'inst.repo' in the PXE menu file and it still fails.

Let me know if something isn't clear. Any pointers will be helpful. Thanks.

I am working on setting up a PXE based automated installation in our environment. As part of that, I want to install few additional packages via the kickstart file during the build. These packages aren't part of the standard ISO that CentOS provides (i.e.) it isn't available in the 'Packages' directory. So, I copied the required RPMs manually to the 'Packages' directory and ran 'createrepo --update .' but it didn't help. I looked around for any potential alternatives but couldn't find any.

I understand that I can install these packages via yum but I want them to be installed during the build and I don't want to mention these explicitly in the post install section as it defeats the purpose of having the %packages scriptlet in the kickstart file.

Any pointers on how to make the Packages directory in the CentOS ISO aware of the RPMs that I copied into it?

-Ram

I am working on standardizing different bits in our environment and as part of that would like to move towards ssh key based authentication.

Currently we have individual accounts in each servers (around 150-200 of them) and thankfully we keep the uid/gid/username same across most of these servers.It becomes difficult to add/remove users in each host when someone joins or leaves the firm. Generally, there is a software account for each team and members of the team ssh to the servers as a software account by entering the accounts password.

To ease our administration, I will be introducing puppet in the environment and want to use ssh_authorized_key puppet resource to update the software accounts authorized key file with the public key of the users.

In my understanding, this will be like:

ssh_authorized_key { 'Ram': user => '', type => 'ssh-rsa', key => '', }

ssh_authorized_key { 'Shyam': user => '', type => 'ssh-rsa', key => '', }

So, how do I make sure this public key is same across all the servers for a particular user? For example, if the user 'Ram' tries to ssh to server 'hostA' from any server, the same public-private key pair should be used.

Any pointers on how can I have that maintained? Please let me know if something isn't clear. Thanks in advance.

-Ram

I am working on setting up DNS in our environment. In the test bed, I was creating some A records and PTR records in the forward and reverse lookup zone files. So, I was wondering instead of adding the records manually in two places, will we able to generate the PTR records programmatically based on the A records mentioned in the forward lookup zone file.

Does anyone have inputs on how this can be done?

FWIW, I did come across this script mkrdns.pl from http://www.mkrdns.org/ but that script is throwing below error message. I tried looking around but in vain.

Seems the script is not in active development as the last stable version was released way back in 2002.

./mkrdns-3_3.pl -d /etc/named.conf 

<snip>
(debug) Network "arpa.ip6.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.1", View "default", File "/var/named/dynamic/named.loopback", Type "master".

(fatal) The zone file "/var/named/dynamic/named.loopback" is being used by two zones!  Error in config file!

(default:1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa and default:1.0.0.127.in-addr.arpa ...)

I recently found one of our production server (running RHEL7) doesn’t have the root disk mirrored. So, we thought of using one of the spare disks (which has some junk data) for mirroring the root disk using mdraid.

I wanted to do it without disturbing anything on the server as it’s in production. I was checking how to do this with mdraid but couldn’t find anything that’s helpful.

Can someone please let me know how I can mirror the existing root disk with RAID 1 using mdraid?

Thanks in advance.

-Ram

I am still novice in the world of storage. I am working on a project of migrating our backups infra from Solaris to Linux.

As part of that, I have rebuilt a server to Linux (RHEL7) and it has 2 root disks (300GB each) and 30 disks (of 3TB each) from 2 Xyratex shelves (24+6). One of the 2 Xyratex shelves (the one with 24 disks) has a multipath configured.

And as Linux kernel detects each shared drive once through each path, fdisk -l output is listing 102 3TB disks (instead of actual 30).

$ fdisk -l | grep '3000.6 GB' | wc -l
102

Out of which:

48 are multipath devices.

$ fdisk -l | grep '/dev/mapper/mpath*' | grep -v '3000.6' | wc -l
48

One entry for example is:

Disk /dev/mapper/mpathb: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors

And 30 are the actual disks (24+6):

Disk /dev/sdaa: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdab: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdac: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdad: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdaf: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdae: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdai: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdah: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdam: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdal: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdao: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdan: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdaj: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdav: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdaw: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdax: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdaz: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sday: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdba: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdbc: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdbb: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdaq: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdbd: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdap: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdag: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdau: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdas: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdar: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdak: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdat: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors

And 24 are redundant devices:

Disk /dev/sde: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdd: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdf: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdg: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdh: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdk: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdl: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdc: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdo: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdi: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdm: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sds: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdp: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdu: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdw: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdq: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdr: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdn: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdt: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdv: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdy: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdx: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdz: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors
Disk /dev/sdj: 3000.6 GB, 3000592982016 bytes, 5860533168 sectors

Now, I am confused what’s the right way to configure the RAID.

I was planning to have below RAID configuration (reserve 6 disks as spares):

• Create 3 RAID 6 groups with 8 disks each (6 disks and 2 spares).
• 1 RAID 0 on top of the three RAID 6s - so basically there will all look as one unit with RAID 0.
• Then create PV on top of the RAID 0 and then use LVM.

I was reading about having multipath in mdadm but it’s little unclear to me on how I should proceed further. Any thoughts on this?