Enabling Remote Command Execution in Redhat Satellite

October 16, 2014November 29, 2014 / Christopher Paquin

As many of you know, a very useful feature of Redhat Satellite is the ability to execute remote commands on a set of servers. You pick a set of servers and plug in your command and schedule the job. Most of the time these remote commands run just fine, however they can error out if the server is not configured to allow remote command execution. Let’s discuss how to fix this.

If remote command execution is not allowed, you will probably see an error similar to those shown below,

Local permission not set for action type script.run

Invalid function call attempted

Note that these two error messages usually mean the same thing. You need to enable remote command execution on the remote server.

First off you need to make sure that the command rhn-actions-control is installed. If it is not then we first figure out which rpm provides the command. You can do so with the command below

# yum whatprovides */rhn-actions-control

Now that we know what to install, lets install it.

# yum -y install rhncfg-actions

Now we enable remote command execution

# rhn-actions-control –enable-all

Now you should be able to reschedule your job against the server via the webUI.

Linux:How To Restart/Start/Stop Network Interface

‘Shell Shock’ command line vulnerability present in OS X, could be bigger than Heartbleed

RHEL6 – How to Manually Logout of an Iscsi Disk

August 27, 2012November 28, 2014 / Christopher Paquin / Leave a comment

One of the issues that I have run into in the past when working with iscsi disks occurs when a host (initiator) is unable to logout gracefully from an iscsi disk when attempting to shutdown or reboot a host.

Note that this is a known issue and is documented here and here. I have not read completely through the RHEL 6 Bugzilla to see if the issue has been resolved, however I can tell you that I have seen this issue in RHEL 6.2.

Anyway as a quick work around to save yourself a painfully slow reboot you can logout of the disk before you shutdown to save time, for example, if you were taking some sort of linux test.

First think I do is verify that I actually currently am logged into an iscsi session

# iscsiadm -m session
tcp: [1] 10.1.224.34:3260,1 iqn.2012-08.my.new.iscsi

Next I umount the mounted filesystem that was on the iscsi disk. In my case I mounted it to /iscsi_disk

UUID="4f3f136d-1f90-4e1b-95b6-d3496d54da99" /iscsi_disk ext4 defaults,_netdev 0 0

Above is the line in my /etc/fstab that mounts the iscsi disk, note that you should always use the _netdev option to mount a remote disk (nfs, san, iscsi — does not matter)

So after unmounting the disk I manually log out from the iscsi disk/s

iscsiadm -m node –logout all

The output of the command above shows me that the logout was successful.

Logging out of session [sid: 1, target: iqn.2012-08.my.new.iscsi, portal: 10.1.224.34,3260]
Logout of [sid: 1, target: iqn.2012-08.my.new.iscsi, portal: 10.1.224.34,3260] successful.

I can then check my current connected sessions again and see that I have no active sessions.

# iscsiadm -m session
iscsiadm: No active sessions.

Now you should be able to reboot without issue.

As a side note I was actually wondering how the initiator knew to log back into the iscsi disk at boot time. Well if you look in /var/lib/iscsi/nodes/ you will see a directory for each iscsi disk that you logged into using iscsiadm.

RHEL6 – Getting Up Close and Personal With Rsyslog

August 13, 2012November 28, 2014 / Christopher Paquin / Leave a comment

Rsyslog has replaced Syslog as the default logging daemon in RHEL6. Rsyslog was designed to complete with syslog-ng and has several enhancements over plain old syslog. This includes but is not limited to more granularity with timestamps, direct database logging, TCP support, and relay server names in host fields which makes it easier to track the path a message has taken.

Below we are going to take a look at a few simple rsyslog configuration items.

Configure Rsyslog to Accept Remote Logs.

Within /etc/rsyslog.conf, comment out either the TCP or UDP syslog reception lines below. TCP is more reliable, however UDP is more widely supported.

# Provides UDP syslog reception
#$ModLoad imudp.so
#$UDPServerRun 514

# Provides TCP syslog reception
#$ModLoad imtcp.so
#$InputTCPServerRun 514

Configure a Server to Send Logs to a Remote Host.

To send all messages of info priority or higher to a remote host via udp, use the following format. Note that 10.1.224.34 is the remote server that I want to send logs to.

*.info @10.1.224.34

To send the same priorities to the remote host via TCP, use two "@@"

*.info @@10.1.224.34

Note that you can specify the port number on which to send by using IP:PORT. When no port is specified the default port of 514 is used.

Note that depending on your configuration you may need to alter your IPtables configuration on your sending and/or receiving server. In my case I needed to allow UDP on port 514 on my remote syslog server. To accomplish this I used system-config-firewall-tui which added the following line to /etc/sysconfig/iptables.

-A INPUT -m state –state NEW -m udp -p udp –dport 514 -j ACCEPT

Which shows up as what you see below in the output of 'iptables -L'

ACCEPT udp – anywhere anywhere state NEW udp dpt:syslog

Testing Your Configuration

Ok lets send a test to our remote syslog server. Note that rsyslog has been restarted on both hosts.

^{# logger "testing to remote rsyslog server"}

Checking the messages file on the remote host we can see that the test message has arrived.

Aug 13 14:55:26 vfatmin02 root: testing to remote rsyslog server

FATMIN

OpenStack / Cloud / Virtualization / Linux

remote