Archives For systems administration

FirewallD, or Dynamic Firewall Manager, is the replacement for the IPTables firewall in Red Hat Enterprise Linux. The main improvement over IPTables is the capacity to make cahnges without the need to restart the whole firewall service.

FirewallD was first introduced in Fedora 18 and has been the default firewall mechanism for Fedora since then. Finally this year Red Hat decided to include it in RHEL 7, and of course it also made its way to the different RHEL clones like CentOS 7 and Scientific Linux 7.

Checking FirewallD service status

To get the basic status of the service simply use firewall-cmd --state.

[root@centos7 ~]# firewall-cmd --state
[root@centos7 ~]#

If you need to get a more detailed state of the service you can always use systemctl command.

[root@centos7 ~]# systemctl status firewalld.service
firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
   Active: active (running) since Wed 2014-11-19 06:47:42 EST; 32min ago
 Main PID: 873 (firewalld)
   CGroup: /system.slice/firewalld.service
           └─873 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Nov 19 06:47:41 centos7.vlab.local systemd[1]: Starting firewalld - dynamic firewall daemon...
Nov 19 06:47:42 centos7.vlab.local systemd[1]: Started firewalld - dynamic firewall daemon.
[root@centos7 ~]#

To enable or disable FirewallD again use systemctl commands.

systemctl enable firewalld.service
systemctl disable firewalld.service

Managing firewall zones

FirewallD introduces the zones concept, a zone is no more than a way to define the level of trust for a set of connections. A connection definition can only be part of one zone at the same time but zones can be grouped  There is a set of predefined zones:

  • Public – For use in public areas. Only selected incoming connections are accepted.
  • Drop – Any incoming network packets are dropped, there is no reply. Only outgoing network connections are possible.
  • Block – Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4 and icmp6-adm-prohibited for IPv6. Only network connections initiated within this system are possible.
  • External – For use on external networks with masquerading enabled especially for routers. Only selected incoming connections are accepted.
  • DMZ – For computers DMZ network, with limited access to the internal network. Only selected incoming connections are accepted.
  • Work – For use in work areas. Only selected incoming connections are accepted.
  • Home – For use in home areas. Only selected incoming connections are accepted.
  • Trusted – All network connections are accepted.
  • Internal – For use on internal networks. Only selected incoming connections are accepted.

By default all interfaces are assigned to the public zone. Each zone is defined in its own XML file stored in /usr/lib/firewalld/zones. For example the public zone XML file looks like this.

root@centos7 zones]# cat public.xml
<?xml version="1.0" encoding="utf-8"?>
  <description>For use in public areas. You do not trust the other computers on networks to not harm your computer. Only selected incoming connections are accepted.</description>
  <service name="ssh"/>
  <service name="dhcpv6-client"/>
[root@centos7 zones]#

Retrieve a simple list of the existing zones.

[root@centos7 ~]# firewall-cmd --get-zones
block dmz drop external home internal public trusted work
[root@centos7 ~]#

Get a detailed list of the same zones.

firewall-cmd --list-all-zones

Get the default zone.

[root@centos7 ~]# firewall-cmd --get-default-zone
[root@centos7 ~]#

Get the active zones.

[root@centos7 ~]# firewall-cmd --get-active-zones
  interfaces: eno16777736 virbr0
[root@centos7 ~]#

Get the details of a specific zone.

[root@centos7 zones]# firewall-cmd --zone=public --list-all
public (default, active)
  interfaces: eno16777736 virbr0
  services: dhcpv6-client ssh
  masquerade: no
  rich rules:

[root@centos7 zones]#

Change the default zone.

firewall-cmd --set-default-zone=home

Interfaces and sources

Zones can be bound to a network interface and to a specific network addressing or source.

Assign an interface to a different zone, the first command assigns it temporarily and the second makes it permanently.

firewall-cmd --zone=home --change-interface=eth0
firewall-cmd --permanent --zone=home --change-interface=eth0

Retrieve the zone an interface is assigned to.

[root@centos7 zones]# firewall-cmd --get-zone-of-interface=eno16777736
[root@centos7 zones]#

Bound the zone work to a source.

firewall-cmd --permanent --zone=work --add-source=

List the sources assigned to a zone, in this case work.

[root@centos7 ~]# firewall-cmd --permanent --zone=work --list-sources
[root@centos7 ~]#


FirewallD can assign services permanently to a zone, for example to assign http service to the dmz zone. A service can be also assigned to multiple zones.

[root@centos7 ~]# firewall-cmd --permanent --zone=dmz --add-service=http
[root@centos7 ~]# firewall-cmd --reload
[root@centos7 ~]#

List the services assigned to a given zone.

[root@centos7 ~]# firewall-cmd --list-services --zone=dmz
http ssh
[root@centos7 ~]#

Other operations

Besides of Zones, interfaces and Services management FirewallD like other firewalls can perform several network related operations like masquerading, set direct rules and manage ports.

Masquerading and port forwading

Add masquerading to a zone.

firewall-cmd --zone=external --add-masquerade

Query if masquerading is enabled in a zone.

[root@centos7 ~]# firewall-cmd --zone=external --query-masquerade
[root@centos7 ~]#

You can also set port redirection. For example to forward traffic originally intended for port 80/tcp to port 8080/tcp.

firewall-cmd --zone=external --add-forward-port=port=80:proto=tcp:toport=8080

A destination address can also bee added to the above command.

firewall-cmd --zone=external --add-forward-port=port=80:proto=tcp:toport=8080:toaddr=

Set direct rules

Create a firewall rule for 8080/tcp port.

firewall-cmd --direct --add-rule ipv4 filter INPUT -p tcp -m state --state NEW -m tcp --dport 8080 -j ACCEPT

Port management

Allow a port temporary in a zone.

firewall-cmd --zone=dmz --add-port=8080/tcp

Hopefully you found the post useful to start working with FirewallD. Comments are welcome.


Being used to have Cockpit in my Fedora 21 Server VMs I decided that having it also on my CentOS machines would be awesome, unfortunately I quickly found that Cockpit was not available in CentOS repositories. Of course I knew that Cockpit comes installed and enabled by default in CentOS 7 Atomic host image so I figured out that those packages had to be hidden in some Atomic related repo.

After looking a bit I finally found in GitHub the sig-atomic-buildscripts repository that belongs to CentOS Project. This repository contains several scripts and files intended to build your own CentOS Atomic host including virt7-testing.repo, the Yum repository file needed for Cockpit.

Clone the GutHub repository.

git clone

Copy virt7-testing.repo file to /etc/yum.repos.d and install Cockpit.

yum install cockpit

Enable Cockpit service.

[root@webtest ~]# systemctl enable cockpit.socket
ln -s '/usr/lib/systemd/system/cockpit.socket' '/etc/systemd/system/'
[root@webtest ~]#

Add Cockpit to the list of trusted services in FirewallD.

[root@webtest ~]# firewall-cmd --permanent --zone=public --add-service=cockpit
[root@webtest ~]#
[root@webtest ~]# firewall-cmd --reload
[root@webtest ~]#
[root@webtest ~]# firewall-cmd --list-services
cockpit dhcpv6-client ssh
[root@webtest ~]#

Start Cockpit socket.

systemctl start cockpit.socket

Do no try to access Cockpit yet, there is an issue about running Cockpit on stock CentOS/RHEL 7. To be able to start it we need first to modify the service file to disable SSL.Edit file /usr/lib/systemd/system/cockpit.service and modify ExecStart line to look like this.

ExecStart=/usr/libexec/cockpit-ws --no-tls

I know this procedure will invalidate Cockpit for a production environment in RHEL7 at least for now but this is for my lab environment and I can live with it.

Reload systemd.

systemctl daemon-reload

Restart Cockpit.

systemctl restart cockpit

Access Cockpit web interface, login as root and have fun :-)

Screen Shot 2015-01-09 at 01.57.51



VMware has released VMware vSphere Mobile Watchlist. It is available for Android and iOS, iPhone only for now, and will enable any system administrator to keep an eye on their most critical apps from their phones.

It is a very intuitive app to use, below are a series of screenshots from the app installed on my iPhone 5 and connected to my homelab vCenter Server.

From the main screen you can add virtual machines from your vCenter inventory to the default watchlist or create a new watchlist.

Once you have added several virtual machines to your list you can check them in a glance in list or grid mode.

VM watchlist

Tap on a VM and you will access its details, configured resources, VM Tools state, related objects, etc.

As you can see from the screenshot this a multi screen so slide to the left and you can get a console screenshot of the virtual machine and perform different actions on the virtual machine.

Console screenshot    

I hope this is a step towards a new set of mobile apps from VMware focused on the administration of the different components of a virtual and cloud infrastructure :)


ESXi 5.1 comes with many improvements and one of them is new namespaces and commands in esxcli.

Those new commands enable a system administrator to perform a shutdown, a reboot or a maintenance operation in a host.

Under the system namespace the new commands are the equivalents of the classic vicfg/esxcfg-hostops which until now was the only way to perform such kind of operations with vCLI and are also accessible locally on ESXi Shell.


Maintenance mode operations

Getting the basic usage of the command is as simple as always. You can perform two operations.

  • Get the state of the host
  • Put the the host in or out of Maintenance Mode
~ # esxcli system maintenanceMode 
Usage: esxcli system maintenanceMode {cmd} [cmd options]
Available Commands: 
  get                   Get the maintenance mode state of the system. 
  set                   Enable or disable the maintenance mode of the system. 
~ #
  • Get the state of the host
~ # esxcli system maintenanceMode get 
~ #
  • Put the host in Maintenance Mode
~ # esxcli system maintenanceMode set -e true -t 0 
~ # 
~ # esxcli system maintenanceMode get 
~ #

Power operations

With the shutdown command the host can be either rebooted or shutdown. If the ESXi server is not in Maintenance Mode mode the operation will not be allowed.

~ # esxcli system shutdown 
Usage: esxcli system shutdown {cmd} [cmd options]
Available Commands: 
  poweroff              Power off the system. The host must be in maintenance mode. 
  reboot                Reboot the system. The host must be in maintenance mode. 
~ #

For both task the delay and reason parameter must be provided.

~ # esxcli system shutdown poweroff 
Error: Missing required parameter -r|--reason
Usage: esxcli system shutdown poweroff [cmd options]
  poweroff              Power off the system. The host must be in maintenance mode.
Cmd options: 
  -d|--delay=<long>     Delay interval in seconds 
  -r|--reason=<str>     Reason for performing the operation (required) 
~ #
  • Power off the host
~ # esxcli system shutdown poweroff --delay=10 --reason=”Hardware maintenance”
  • Reboot the host
~ # esxcli system shutdown reboot -d 10 –r “Patches applied”


After my previous post about getting the iqn of an ESXi using esxcli Andy Banta (@andybanta) commented on Twitter that you can also change the iqn of the host with esxcli.

As he said it would be tremendously useful if you need to physically replace the server and don’t want to modify all your storage infrastructure, it’s easier to just modify the iqn of the new server and set it to the old name.

The task is as easier as the one described in last post. Using esxcli command with the iscsi namespace you can change the name and the alias of the adapter.

Screenshot from 2012-08-02 21_15_52

As a precaution first retrieve the current iqn to check that it’s the correct server.

Screenshot from 2012-08-02 21_20_08

To change the name you have to provide the adapter and the new name.

Screenshot from 2012-08-02 21_22_03

Hope you find this useful, any comments and suggestions are welcome as always.


Back in 2010 I wrote a post about how to get the iSCSI iqn of an ESXi 4.x server using vSphere CLI from the vMA or any other system with the vCLI installed on it.

The method described in that article is still valid for ESXi 5.0 since the old vicfg and esxcfg commands are still available, however with 5.0 version you can get a similar result using the new esxcli namespaces, following is how to do it.

First task is to get a list of the iSCSI HBAs in order to know the name of the software iSCSI initiator.


Next we get the info of the adapter.


Look at the Name field to get the iqn and we are done.


If your vCSA is configured to use the embedded DB2 database and if it’s not properly shutdown, next you power it on may be you should not be able to power on a VM like in the screenshot below…


…or the vSphere Client will not show some of information about the host or the VMs.


We all have seen those kind of errors in our homelabs from time to time. In the Windows-based vCenter it was relatively easy to solve, close the client, log into the vCenter, restart the vCenter Server service and in the next login into the vSphere Client everything will go as expected.

However how can we resolve this issue in the vCenter Linux appliance? Can’t be easier.

There are two ways to restart the vCenter services in the vCSA:

  • From he WebUI administration interface
  • From the command line

For the first method log into the WebUI of the vCSA by accessing https://<vCSA_URL>:5480 with your favorite web browser.


In the vCenter Server screen in the Status tab there stop and start the vCenter Server service from the Action buttons.

The second method is faster and easier, and to be sincere it feels more natural for me and probably for the other Unix Geek/Sysadmins out there.

The vCenter service in the Linux appliance is vmware-vpxd so with a simple service vmware-vpxd restart we’ll be on business again. Check the screenshot below.


Finally as seen in the screen capture you can check the status of the service.

More on troubleshooting the vCSA in a future post.


Last week vSphere 5 Update 1 was released by VMware, along with the main products some of the SDKs and automation tools were also updated, including the vMA.

As you should remember from my first post about vMA 5 the classic vma-update utility is no longer available. So to be able to update our vMA to the new version we have to use the Web UI. Following is the procedure to perform the upgrade.

First access the web interface using the vi-admin user as always.


From the main screen go to the Update tab. In the Status screen click on Check Updates.


After a few seconds a message will appear showing the new update available.


Click on Install Updates and after asking for confirmation the update process will start.


Once the update process is complete the appliance will ask for a system reboot.


Go to the System tab and perform the reboot. After the reboot is done you can check the new version in the appliance console,


And in the /etc/vma-release file.

vi-admin@vma:~> cat /etc/vma-release
vMA 5.0.0 BUILD-643553

Copyright (C) 1998-2011 VMware, Inc. All rights reserved.
This product is protected by U.S. and international copyright and
intellectual property laws. VMware products are covered by one or more U.S.
Patent Numbers D617,808, D617,809, D617,810, D617,811, 6,075,938,
6,397,242, 6,496,847, 6,704,925, 6,711,672, 6,725,289, 6,735,601,
6,785,886, 6,789,156, 6,795,966, 6,880,022, 6,883,095, 6,940,980,
6,944,699, 6,961,806, 6,961,941, 6,970,562, 7,017,041, 7,055,032,
7,065,642, 7,069,413, 7,069,435, 7,082,598, 7,089,377, 7,111,086,
7,111,145, 7,117,481, 7,149,310, 7,149,843, 7,155,558, 7,222,221,
7,260,815, 7,260,820, 7,269,683, 7,275,136, 7,277,998, 7,277,999,
7,278,030, 7,281,102, 7,290,253, 7,343,599, 7,356,679, 7,386,720,
7,409,487, 7,412,492, 7,412,702, 7,424,710, 7,428,636, 7,433,951,
7,434,002, 7,447,854, 7,447,903, 7,467,067, 7,475,002, 7,478,173,
7,478,180, 7,478,218, 7,478,388, 7,484,208, 7,487,313, 7,487,314,
7,490,216, 7,500,048, 7,506,122, 7,516,453, 7,529,897, 7,543,301,
7,555,747, 7,565,527, 7,571,471, 7,577,722, 7,581,064, 7,590,715,
7,590,982, 7,594,111, 7,596,594, 7,596,697, 7,599,493, 7,603,704,
7,606,868, 7,620,523, 7,620,766, 7,620,955, 7,624,240, 7,630,493,
7,636,831, 7,657,659, 7,657,937, 7,665,088, 7,672,814, 7,680,919,
7,689,986, 7,693,996, 7,694,101, 7,702,843, 7,707,185, 7,707,285,
7,707,578, 7,716,446, 7,734,045, 7,734,911, 7,734,912, 7,735,136,
7,743,389, 7,761,917, 7,765,543, 7,774,391, 7,779,091, 7,783,779,
7,783,838, 7,793,279, 7,797,748, 7,801,703, 7,802,000, 7,802,248,
7,805,676, 7,814,495, 7,823,145, 7,831,661, 7,831,739, 7,831,761,
7,831,773, 7,840,790, 7,840,839, 7,840,993, 7,844,954, 7,849,098,
7,853,744, 7,853,960, 7,856,419, 7,856,531, 7,856,637, 7,865,663,
7,869,967, 7,886,127, 7,886,148, 7,886,346, 7,890,754, 7,895,437,
7,908,646, 7,912,951, 7,921,197, 7,925,850; patents pending.
VMware, the VMware "boxes" logo and design, Virtual SMP and VMotion are
registered trademarks or trademarks of VMware, Inc. in the United States
and/or other jurisdictions. All other marks and names mentioned herein may
be trademarks of their respective companies.

The above procedure use the default VMware repository and your appliance must be able to resolve public DNS addresses and access the internet in order to download de upgrade bits.


suse_linux_logo1Getting SUSE Enterprise Linux integrated with Microsoft Active Directory is much easier than it sounds.

There are a few prerequisites to meet before:

  • Samba client must be installed.
  • Packages samba-winbind and krb5-client must be installed.
  • The primary DNS server must be the Domain Controller.

For this task we will use YaST2, the SUSE configuration tool.

YaST2 can be run either in graphical…

Screenshot-YaST2 Control Center-1

…or in text mode.


I decided to use the text mode since it will be by far the most common use case, anyway in both cases the procedure is exactly the same.

Go to Network Services section and later select Windows Domain Membership. The Windows Domain Membership configuration screen will appear.

In the Membership area enter the domain name and configure the options that best suit your environment, including the other sections of the screen.


I configure it to allow SSH single sign-on, more on this later, and to create a home directory for the user on his first login.

You should take into account the NTP configuration since it’s a critical component in Active Directory authentication.

Select OK to acknowledge your selection and a small pop-up will show up to inform that the host is not part of the domain and if you want to join it.


Next you must enter the password of the domain Administrator.


And YaST will finally confirm the success of the operation.


At this point the basic configuration is done and the server should be integrated on the Windows Domain.

Under the hood this process has modified several configuration files in order the get the system ready to authenticate against Active Directory:

  • smb.conf
  • krb5.conf
  • nsswitch.conf


The first is the configuration file for the samba service. As you should know Samba is an open source implementation of the Windows SMB/CIFS protocol, it allows Unix systems to integrate almost transparently into a Windows Domain infrastructure and also provides file and print services for Windows clients.

The file resides in /etc/samba. Take a look at the contents of the file, the relevant part is the global section.

        workgroup = VJLAB
        passdb backend = tdbsam
        printing = cups
        printcap name = cups
        printcap cache time = 750
        cups options = raw
        map to guest = Bad User
        include = /etc/samba/dhcp.conf
        logon path = \\%L\profiles\.msprofile
        logon home = \\%L\%U\.9xprofile
        logon drive = P:
        usershare allow guests = No
        idmap gid = 10000-20000
        idmap uid = 10000-20000
        realm = VJLAB.LOCAL
        security = ADS
        template homedir = /home/%D/%U
        template shell = /bin/bash
        winbind refresh tickets = yes


The krb5.conf is the Kerberos daemon configuration file which contains the necessary information for the Kerberos library.

jreypo@sles11-01:/etc> cat krb5.conf
        default_realm = VJLAB.LOCAL
        clockskew = 300
        VJLAB.LOCAL = {
                kdc = dc.vjlab.local
                default_domain = vjlab.local
                admin_server = dc.vjlab.local
        kdc = FILE:/var/log/krb5/krb5kdc.log
        admin_server = FILE:/var/log/krb5/kadmind.log
        default = SYSLOG:NOTICE:DAEMON
        .vjlab.local = VJLAB.LOCAL
        pam = {
                ticket_lifetime = 1d
                renew_lifetime = 1d
                forwardable = true
                proxiable = false
                minimum_uid = 1


The nsswitch.conf file as stated by its man page is the System Databases and Name Service Switch configuration file. Basically it includes the different databases of the system to look for authentication information when user tries to log into the server.

Have a quick look into the file and you will notice the two fields changed, passwd and group. In both the winbind option has been added in order to indicate the system to use Winbind, the Name Service Switch daemon used to resolve NT server names.

passwd: compat winbind
group:  compat winbind

SSH single sign-on

Finally we need to test the SSH connection to the host using a user account of the domain. When asked for the login credentials use the DOMAIN\USER formula for the user name.


This kind of integration is very useful, specially for the bigger shops, because you don’t have to maintain the user list of your SLES servers individually, just only the root account since the other accounts can be centrally managed from the Windows Domain.

However there is one issue that must be taken into account, the SSH single sign-on authentication means that anyone with a domain account can log into your Linux servers and we don’t want that.

To prevent this potentially dangerous situation we are going to limit the access only to those groups of users that really need it. I’m going to use the Domain Admins to show you how.

First we need to look for the Domain Admins group ID within our Linux box. Log in as DOMAIN\Administrator and use the id command to get the user info.

VJLAB\administrator@sles11-01:~> id
uid=10000(VJLAB\administrator) gid=10000(VJLAB\domain users) groups=10000(VJLAB\domain users),10001(VJLAB\schema admins),10002(VJLAB\domain admins),10003(VJLAB\enterprise admins),10004(VJLAB\group policy creator owners)

There are several group IDs, for our purposes we need the VJLAB\domain admins which is 10002.

You should be asking yourself, but the GID is not 10002 but 10000? Yes you are right and because of that we need to make some changes at Domain Controller level.

Fire up Server Manager and go to Roles –> Active Directory Domain Services –> Active Directory Users and Computers –> DOMAIN –> Users.


On the right pane edit the properties of the account you want to be able to access the linux server via SSH. In my case I used my own account juanma. In the Member of tab select the Domain Admins group and click Set Primary Group.


Now we need to modify how the pam daemon manage the authentication. Go back to SLES and edit /etc/pam.d/sshd.

auth     requisite
auth     include        common-auth
account  include        common-account
password include        common-password
session  required
session  include        common-session

Delete the account line and add the following two lines.

account  sufficient
account  sufficient gid = 10002

The sshd file should look like this:

auth     requisite
auth     include        common-auth
account  sufficient
account  sufficient gid = 10002
password include        common-password
session  required
session  include        common-session

What we did? First eliminated the ability to login via SSH for every user and later we allow the server local users and the Domain Admins to log into the server.

And we are done. Any comment would be welcome as always :-)


Yes another post about esxcli, what can I say I’m studying very hard for my VCP5 and from time to time this kind of unknown information, at least for me, arise and I believe it can be useful for some of you.

Again we are going to make use of the system namespace.

~ # esxcli system hostname
Usage: esxcli system hostname {cmd} [cmd options]
Available Commands:
  get                   Get the host, domain or fully qualified name of the ESX host.
  set                   This command allows the user to set the hostname, domain name or fully qualified domain name of the ESX host.
~ #

First task of course is to get current hostname.

~ # esxcli system hostname get
   Domain Name: vjlab.local
   Fully Qualified Domain Name: esxi5.vjlab.local
   Host Name: esxi5
~ #

Next change the hostname, but you should check before what options are at your disposal by getting the command help.

~ # esxcli system hostname set --help
Usage: esxcli system hostname set [cmd options]
  set                   This command allows the user to set the hostname, domain name or fully qualified domain name of the ESX host.
Cmd options:
  -d|--domain=<str>     The domain name to set for the ESX host. This option is mutually exclusive with the --fqdn option.
  -f|--fqdn=<str>       Set the fully qualified domain name of the ESX host.
  -H|--host=<str>       The host name to set for the ESX host. This name should not contain the DNS domain name of the host and can only contain letters, numbers and '-'. NOTE this is not
                        the fully qualified name, that can be set with the --fqdn option. This option is mutually exclusive with the --fqdn option.
~ #

Interesting, you can change the short hostname, the domain or the fully qualified domain name. Take into account that --fqdn option is mutually exclusive with the others.

We are going to try all of them.


~ # esxcli system hostname set --domain=jreypo.local
~ #
~ # esxcli system hostname get
   Domain Name: jreypo.local
   Fully Qualified Domain Name: esxi5.jreypo.local
   Host Name: esxi5
~ #

Short hostname:

~ # esxcli system hostname set --host=esxi5-2
~ #
~ # esxcli system hostname get
   Domain Name: jreypo.local
   Fully Qualified Domain Name: esxi5-2.jreypo.local
   Host Name: esxi5-2
~ #

Fully qualified domain name:

~ # esxcli system hostname set --fqdn=esxi5.vjlab.local
~ #
~ # esxcli system hostname get
   Domain Name: vjlab.local
   Fully Qualified Domain Name: esxi5.vjlab.local
   Host Name: esxi5
~ #