drkmkzs's questions

I'm configuring a cluster 2 nodes with pacemaker/corosync, and I have some question about it (and maybe best practice : i'm far to be specialist)

**OS:** redhat 7.6

I configurated the cluster with those properties

 - **stonith-enabled:** true

 - **symmetric-cluster:** true (even if is default value i think)


and added in corosync.conf

 - **wait_for_all:** 0 (i want a Node be able to start/work even if his twin is KO)

 - **two_nodes:** 1


Considering the fencing:

- Using ILO of blade HP (ILO1 for Node1, ILO2 for Node2)

I read that it was sometimes a good practice to prevent a node suicide, so added constraints 

- ILO1-fence can't locate in node1 

- ILO2-fence can't locate on node2

The problems I have is the following, happening at starting Node2 when Node1 is shutdown :

• pacemaker/corosync can't start ILO2-fence on Node1 (of course cause Node 1 is down), and so don't start the other resources, and so my cluster is all not working >:[

I am wondering if I miss something in my configuration, or if I don't understand well how such a cluster should work.

Because I'd expect Node2 to start, cluster sees Node1 is KO and just start the resources to make Node2 works on its own.

But is true, since ILO2-fence can only be located on Node1 (because of constraint to avoid suicide), then this resource will always fails ... (when trying without those "anti-suicide" constraints, if Node2 has some services failure, then it shutdowns directly after start, which i don't want)

I would apreciate some returns and enlightments :)

Thank you :)

I would like to retrieve the windows user in a webapp.

Currently using Kerberos/Apache/Tomcat, the variable REMOTE_USER is set in http header so is fine.

But now my needs have changed :

• no more client authentication (no more Kerberos)
• user should not have to log into webapp
• need username to check some process from DB or LDAP

I was wondering what would be the cleaner way to pass the information ?

Thank you

As title says, on one of my BL460, i have a RedHat installed, and a recurrent message in /var/log/messages from mcelog deamon, telling me:

mcelog: Corrected memory errors on page 61a5dd000 exceed threshold 10 in 24h: 10 in 24h mcelog: Location SOCKET:1 CHANNEL:1 DIMM:0 [] mcelog: Offlining page 61a5dd000 mcelog: Offlining page 61a5dd000 failed: Input/output error

I have two questions:

1. Is the message is "normal", i mean the system see errors, correct them, and then after all corrections I shouldn't have those errors anymore in /var/log/messages ? (even tho it means some dimm module has some errors)

2. I try to locate the DIMM module, but i don't find it. I located the PROC 1 of BL, and the CHANNEL 1 pair. But in BL460, DIMM or listed as 1 to 6 . I assumed DIMM:0 was the physical DIMM 1, but after removing it but the message still appears in /var/log/messages. (then I removed 1 and 2 after to check because both are CHANNEL1, but still same) How can I understand which physical DIMM it is ?

Thank you :)

I have a little problem with my HP 6125G Blade Switch. Just to precise, I don't understand much IRF configuration.

So i have a hp C7000 blade systems, with embeded blade switches (4). The switches are configured as an IRF stack. 2 servers and some blades are plugged on the switches (and a disk bay), all in a single VLAN.

My problem is : On my server, "someone" is sending a DHCPDISCOVER request each 7 seconds (~). Since the address MAC is mentionned in the /var/log/messages, I know it does not come from any machine (neither server nor blades), and not from the disk bay. So it remains my IRF switches stack : when i do an arp on the management switch address, i see an @MAC that looks like a lot to the @MAC i'm looking for ; if the 4 members have almost similar @MAC, I would suspect one of them to be culprit (and because I don't have any others hardware)

My question is : When connected via SSH on the switch stack, how can I check the @MAC of each member ? I looked the configuration, as far as I understand (very far) all I can see related to mac address is the option irf mac-address persistent timer

Sorry if I don't use the correct terms, any answer/advice/explanation is welcome

Thanx :)

I am currently trying to set a server/client configuration, and i'm struggling a little with snmp behaviour. Just to precise, i'm not really into linux administration, nor network administration, so don't be surprised if my questions are sometimes newbie ones.

My architecture is the following :

• 2 servers on rhel6, with ip xxx.xxx.xxx.1 and xxx.xxx.xxx.2
• The 2 servers are configured with cluster suite (failover), so i have a Virtual address: VIP is xxx.xxx.xxx.3 (let's say the master is xxx.xxx.xxx.1 for the discussion)
• N nodes on centos6 (xxx.xxx.xxx.10, xxx.xxx.xxx.11, ...)
• All machines (nodes and servers) are on a unique LAN (no routers, no firewall, no routes, ...)
• No DNS, everything on static on hosts files

I wanted the master server (the one who's the master in cluster) to monitor the nodes with SNMP. So I configured the snmpd file on the nodes, specifying the host with the VIP xxx.xxx.xxx.3. I did the same configuration on the servers, in order to enable the master to monitor the slave server too.

What is happening is the following :

1. When I execute a snmpwalk from the master to a node, i reach a
   timeout. Using tcpdump, I can see the request is well sent by the
   master, and the node receive it. It seeems the node doesn't answer
   corrtectly
2. When I execute a snmpwalk from the master to the slave, everything is ok. If I change the SNMP configuration on node, specifying the host with the master address (xxx.xxx.xxx.1 for instance) it's OK.

So what I think :

• I have read that SNMP is not cluster aware; I feel i am right into the problem but I don't manage to get what's happening. From what i've seen in 1) and 2), I would say the node doesn't answer to the VIP, but the real address of the master (didn't have the time to check with tcmpdump)
• But if it's true, why the snmpwalk on the slave is working ? I would have expected the same behaviour

Should I specify on the nodes both address of servers instead of the VIP, Is it a clean solution (still have to check if it's working) ?

Or do I need to specifically configure the snmp client on the node (snmp.conf) ? I didn't modify this one at all.

Thanx for your help, I'm a little lost in there.

I know this question has been already discussed, but by reading the posts I could not figure the answers, because some said "yes umask can work", and others say "OpenSSH put command always preserve permissions"

Before all just to precise:

• I use OpenSSH 5.9 on RHEL 6.2
• I have configured a chrooted SFTP server, using internal-sftp subsystem, with -u 0002 for umask
• I precise I don't use the -p or -P option

From what I have read on one hand: there are many ways to define umask for SFTP transfers:

• option -u of internal-sftp (or sftp-server) , since OpenSSH 5.4
• create a wrapper to sftp-server (in which we explicitly set the umask - this doesn't fit for chrooted environment btw)
• add a specific configuration in pam.d/sshd file

On the other hand I have read:

The OpenSSH SFTP client and server do transfer the permissions (as an extension) and create the remote file with the permissions on the local side. AFAICT, there is no way to disable this behavior.

So I did the following test:

On my client I created file MYFILE and directory MYDIR with permissions 600 and 700.

Then with sftp commands:

mkdir => the new directory has permissions following the umask (OK)
put MYFILE => MYFILE has same permissions as on client (KO)
put -r MYDIR => MYDIR has same permissions as on client (KO)

If I change permissions of MYFILE and MYDIR on client side, and upload again, I get the new permissions on server side.

I tried the pam.d solution too, but it changed nothing.

So now I'm confused :

From what I tested and a part of what I read, I would say OpenSSH always preserve permissions. But as there are many posts saying that a umask could be defined, I can imagine I do a wrong thing in my test configurations.

I would appreciate some experienced feedback.

Thank you.