Open gnome-terminals with a specific configuration on CentOS 7

I’m a hard-core terminal guy. I do all with it. As such, I hate to open again and again the same group of terminals, give them names, and so on. So, is there any fast way to save and restore tabs of terminals? It turns out that no, there isn’t. If I type on my CentOS 7.6

# > gnome-terminal --version
# GNOME Terminal 3.28.2 using VTE 0.52.2 +GNUTLS
# > gnome-terminal --save-config=/tmp/test
# Option “--save-config” is no longer supported 
in this version of gnome-terminal.

So the nice load-config and save-config are no more. What now? I looked for an alternative, like terminal emulators. Some of them can be installed via yum, and they allow profile management, like ROXTerm. My problem? I run on different computers, and I don’t want to be installing, even via yum, something everywhere just to save 5 minutes. It’s like killing a fly with a canyon. I mostly just want to ssh to different clients, and rename the tab afterwards.

Let’s say I want to open 3 tab in addition to the one I am to client1, client2, and client3. I create an executable file (chmod 777) with this content:

gnome-terminal \
--tab -t client1 -e 'sh -c "ssh -Y client1"' \
--tab -t client2 -e 'sh -c "ssh -Y client2"' \
--tab -t client3 -e 'sh -c "ssh -Y client3"'

I open a new shell, run the and see how 3 additional tabs are opened with my ssh connections established. Note that on the one I run the script I get this deprecation message, but I can keep working on it, so so far so good 🙂

BTW, if you try to correct the “-e” the way they suggest, you will end up with this other error. This script I can copy around, have it in my home folder, or even in my email as a draft, so small it is. And I can have as many as I like, let’s say,, etc. My problem is solved, and my day gone, therefore, have a nice weekend !


A Wiki install on CentOS 7

We need a website that can be used to shared information. This is usually called a wiki. I was tempted to install a wiki on a container (see for example the  xwiki docker) but I went for the real thing due to a weird error with multiple LAMP dockers running on the same host that I didn’t have time to debug. But what wiki style to choose? I chose MediaWiki since it is the Wikipedia layout, but let’s have a look to the other options.

  • DokiWiki is a simple wiki. Here you have the installation procedure for CentOS 7. Why I didn’t choose it? Because it doesn’t have a popular layout, one everybody knows.
  • PhpWiki is an even simpler wiki. Here you have the installation on CentOS 7, and a live version to have a look to it. Again, I’m going to say the layout is not modern enough.
  • Xwiki is indeed looking great, so I could install it instead of MediaWiki. Here you have the installation on CentOS 7. I didn’t chose this one out of my gut’s feeling against a wiki that looks like a social network. Time will say if I’m wrong or not 🙂

I go ahead then with MediaWiki. I need to have at hand is the Manual Installation guide. And first stone I find there is the requirements.  I quote:

On CentOS 7, the default php is 5.4, so how the hell we install 7.X? I found the solution here. At the end, the list of additional packages I installed is this:

yum install
yum install
yum install yum-utils
yum-config-manager --enable remi-php72
yum install php php-mcrypt php-cli php-gd php-curl
php-mysql php-ldap php-zip php-fileinfo mysql postgresql sqlite

I have unzip my mediawiki tarball, move it to /var/www/html/ and point my browser to the local address. But I see a php text instead of the nice installer that you see at the top of this post. What am I doing wrong? Of course, I need to either reboot the computer or restart the apache server. After that, the configuration script runs, and  I have my wiki. Easy as a pie on Ubuntu, I guess. 😛

Package atomic-registries requires python-pytoml error installing docker on CentOS 7

I’m moving dockers around. Most of my machines are Intel running CentOS 7. But on one Opteron running CentOS 7 (but same kernel than the intel) I got the next error when running yum.

yum install docker
..stuff here, repository list, fastest mirrors...
Resolving Dependencies
--> Running transaction check
...the checks here...
---> Package libsepol-devel.x86_64 0:2.5-8.1.el7 
will be an update
--> Finished Dependency Resolution
Error: Package: 1:atomic-registries-XXX.el7.centos.x86_64 (extras)
Requires: python-pytoml
Available: python-pytoml-0.1.14-1.XXX.el7.noarch (extras)
python-pytoml = 0.1.14-1.XXX.el7
Available: python2-pytoml-0.1.18-1.el7.noarch (epel)
python-pytoml = 0.1.18-1.el7
You could try using --skip-broken to work around the problem
You could try running: rpm -Va --nofiles --nodigest

The same command works flawlessly on other machines. Maybe it’s my machine, that has remnants from other installations. Maybe it is Opteron, maybe it’s something else. But let’s fix it. First we better be sure there’s no previous docker installed on the system:

yum remove docker docker-client \ 
docker-client-latest docker-common \
docker-latest docker-latest-logrotate \
docker-logrotate docker-selinux \
docker-engine-selinux docker-engine

Then we apply the official patch to install it.

 wget -qO- | sh

After that, everything seems to work! Time to move my babies around! I want to try to convert my servers to dockers so that I stop doing what I call the dance: this server here, this GPU card there, this RAM removed, this RAM added 🙂 a lonesome and tiring job the one of the moving man 😛

ssh login ignoring bashrc

A small post for a small problem. I was editing my bash profile when I closed all my ssh windows to the remote machine I was working on, just to find out due to my (incomplete) modification I was not able to ssh to it anymore. I tried several options:

ssh -t user@host bash --norc --noprofile

Unfortunately, none of them worked. Since the remote clients were not managed by me, I don’t know the reason. But let’s say the other shells were simply not installed. Anyway I managed to fix it without contacting support. How? I tested my new .bashrc and .bash_profile on a local client, and when I was satisfied, I simply scp them to the remote host. Like this:

scp bashrc user@host:.bashrc
scp basprofile user@host:.bash_profile

On the scp, you can get an error like this:

Error opening terminal: unknown.
bashrc  100% 231 25.0KB/s 00:00

After this, when I try to log in again via ssh to the remote host, everything works. Lesson of the day: always keep a local backup of your remote configurations! :-DThere was another “untested” solution. You can contact another user of the system and ask him to open a ssh shell for you, after that, su to your account. By the way, here you have a nice lecture about login, shells and startup files.

Add a puppet node to a foreman server

I wrote before how to add a puppet node to a foreman docker. I want to add  the same node to the real server, that I call cfore, instead of the dfore docker. On the pnode from the previous example I edit the configuration, so that now  /etc/puppet/puppet.conf points to the server cfore instead of dfore. I’m trying to follow this unixmen guide about how to add puppet nodes to foreman. After the change of the server and restarting the daemon, we get an SSL error.

pnode # > systemctl status puppet
● puppet.service - Puppet agent
 Loaded: loaded (/usr/lib/systemd/system/puppet.service; 
disabled; vendor preset: disabled)
 Active: active (running) since XXX; 5s ago
 Main PID: 25553 (start-puppet-ag)
 CGroup: /system.slice/puppet.service
 ├─25553 /bin/sh /usr/bin/start-puppet-agent agent --no-daemonize
 └─25555 /usr/bin/ruby /usr/bin/puppet agent --no-daemonize

XXX pnode puppet-agent[25569]: 
(/File[/var/lib/puppet/facts.d]) Wrapped exception: 
XXX pnode puppet-agent[25569]: 
SSL_connect returned=1 errno=0 state=error: 
certificate verify failed: [self signed YYY]
XXX pnode puppet-agent[25569]: 
(/File[/var/lib/puppet/lib]) Failed to generate additional 
resources using 'eval_generate': 
SSL_connect returned=1 errno=0...YYY]
XXX pnode puppet-agent[25569]: 
(/File[/var/lib/puppet/lib]) Could not evaluate: 
Could not retrieve file metadata for puppet:]
XXX pnode puppet-agent[25569]: 
...and so on

Now we can check the foreman SSL issues. I believe, anyway, that is more a ruby SSL connection issue, or a puppet SSL mismatch.

So I install the puppetdb tool, and run it to regenerate the SSL certificates:

cfore # > yum install puppetdb
..some stuff here...
 puppetdb noarch 4.4.0-1.el7 puppetlabs-pc1 22 M
Transaction Summary
Install 1 Package
..some stuff here...
 Installing : puppetdb-4.4.0-1.el7.noarch 1/1 
Config archive not found. Not proceeding with migration
PEM files in /etc/puppetlabs/puppetdb/ssl are missing, 
we will move them into place for you
Copying files: /etc/puppetlabs/puppet/ssl/certs/ca.pem, 
/etc/puppetlabs/puppet/ssl/private_keys/ and 
to /etc/puppetlabs/puppetdb/ssl
Backing up /etc/puppetlabs/puppetdb/conf.d/jetty.ini 
to /etc/puppetlabs/puppetdb/conf.d/jetty.ini.bak.1528274270 
before making changes
Updated default settings from package installation for 
ssl-ca-cert in /etc/puppetlabs/puppetdb/conf.d/jetty.ini.
 Verifying : puppetdb-4.4.0-1.el7.noarch 1/1
 puppetdb.noarch 0:4.4.0-1.el7
cfore # > puppetdb ssl-setup -f
PEM files in /etc/puppetlabs/puppetdb/ssl already exists, 
checking integrity.
Overwriting existing PEM files due to -f flag
Copying files: /etc/puppetlabs/puppet/ssl/certs/ca.pem, 
and /etc/puppetlabs/puppet/ssl/certs/ 
to /etc/puppetlabs/puppetdb/ssl
Setting ssl-host in /etc/puppetlabs/puppetdb/conf.d/jetty.ini 
already correct.

As you see, installing puppetdb does do some configuration also.

We have now new SSL certificates. We clean the one of pnode, if it’s there. During my experiments I managed to issue the certificate once, so I clean it  doing puppet cert clean pnode. Now to be sure I reinstall puppet on pnode. It’s quick and it does no harm. I adjust puppet.conf, do more or less as suggested by stackoverflow and:

  • remove manually all remnants of the previous puppet install
  • remove and reinstall the puppet package (yum)
  • restart the puppet agent (puppet agent -t)
  • sign the new certificate on the puppet master
  • restart the puppet service (systemctl start puppet)
pnode # > rm -rf /var/lib/puppet/
pnode # > rm -rf /etc/puppet/
pnode # > yum remove puppet
pnode # > yum install puppet  
pnode # >  puppet agent -t
Info: Creating a new SSL key for
Info: Caching certificate for ca
Info: csr_attributes file loading from 
Info: Creating a new SSL certificate request 
Info: Certificate Request fingerprint (SHA256): 
Info: Caching certificate for ca
Exiting; no certificate found and waitforcert is disabled
cfore # > puppet cert list
 "" (SHA256) :
cfore # > puppet cert sign
Signing Certificate Request for:
 "" (SHA256) :
Notice: Signed certificate request for
Notice: Removing file Puppet::SSL::CertificateRequest at 
pnode # > systemctl start puppet
pnode # > systemctl status puppet
--> OK

If I refresh the foreman web interface, I see also my new client pnode appears after a few minutes. So far so good! Next step, PXE boot from foreman.

Add a puppet node to a foreman docker

There should be no difference between adding a node on a foreman server and on a foreman docker. But the world is not ideal, and things don’t work out of the box, therefore, here’s my HOWTO. The original source is here.

First step is to install a puppet module  on my foreman docker dfore. That I do as written, just to get an error:

dfore # puppet module install -i 
/etc/puppet/environments/production/modules saz/ntp
Notice: Preparing to install into 
/etc/puppet/environments/production/modules ...
Notice: Downloading from ...
Error: No suitable tar implementation found
Error: Try 'puppet help module install' for usage

I need to have tar installed in my docker, that’s it. After it I manage to install it. Next error I experience is with the import of the class.


More or less here. My puppet server was not able to realize the new class. What I did is simply install foreman again inside the docker:

dfore # foreman-installer 
Installing Done [100%] [.........................................]
 * Foreman is running at XXXX
 Initial credentials are admin / changeme
 * Foreman Proxy is running at https://XXXX:8443
 * Puppetmaster is running at port 8140
 The full log is at /var/log/foreman-installer/

I understand we can’t go and install foreman each time we import a puppet module. But let’s say you are starting as I am, that this docker is a playground, and we will not see this issue on a real server. Before testing the puppet agents, I add one node (a real computer) over the foreman web interface. But before adding it, we need to have

  • Its Host Group defined (for example,
  • An OS defined (for example, CentOS 7.4)

If we don’t define these two, we will not manage to fill all the requested information to add the node. As I said, I add my node pclient that runs CentOS 7.4 and on it, install, configure and start puppet. My /etc/puppet/puppet.conf is looking like this:

pclient ~ ## > more /etc/puppet/puppet.conf 
 logdir = /var/log/puppet
 rundir = /var/run/puppet
 ssldir = $vardir/ssl

 #pluginsync = true
 report = true
 #certname = `hostname`
 #environment = production
 server =

NOTE: I don’t give a certname, so pclient is used. At the very beginning I had troubles with this. For example in this howto add an existing VM to foreman, the line is like that: hostname. I understood it as code, so I left it. Wrong. Anyway, it doesn’t look like the best idea to give a specific name to a client, different to the host name itself.

With the naming issue sorted out, we start them the puppet service on the client.

pclient ~ ## > systemctl start puppet

We check the certificate of pclient on our foreman docker, the CA authority:

dfore # puppet cert list
 "" (SHA256) 
dfore # puppet cert sign
Notice: Signed certificate request for 
Notice: Removing file Puppet::SSL::CertificateRequest at 

Your output, of course, will be different. Now we run the agent test.

pclient ~ ## > puppet agent -t
 Warning: Unable to fetch my node definition, 
but the agent run will continue:
 Warning: Error 400 on SERVER: Failed to find via exec: 
Execution of '/etc/puppet/node.rb' 
returned 1:
 Info: Retrieving pluginfacts
 Info: Retrieving plugin
 Info: Caching catalog for
 Info: Applying configuration version 'XXXX'
 Info: Creating state file /var/lib/puppet/state/state.yaml
 Notice: Finished catalog run in 0.05 seconds

We wait a little and check the web interface. Alleluia! pclient is there, together with the cert authority itself. I’m done. Next step: PXE booting test.

A docker cobbler server on CentOS 7

cobbler-mainYes I know, I’m a little bit dense on the last days about the docker thing. But what can I say: this blog is also my notebook/slash/lab book and I want to write here about how I did this or that.

Today, for example, I managed to get rid of my (old) cobbler server. Cobbler is a Linux installation server that allows for rapid setup of network installation environments. Yes I quote. Now what does it mean? It means that, provided you have an ISO image of the OS you want to install, you can mount it in the cobbler server and use the cobbler scripting power to install that OS on the client via PXE, the way you like. I will not tell you how to use it. Or at least, I will not tell you today how to use it. Let’s focus on the installation of a container version of it.

With a quick Google search you arrive to this github cobbler docker definition. I clone the repository on my linux docker master and then I check the blog they suggest. I took the picture from it, actually. I’m going, anyway, to save you (and me) further unnecessary reading and focus on the commands. In the folder you installed the repository, we build an image:

docker build -t cobbler .

Then, let’s say my docker is called supercobbler and I have a free IP on my docker master: I create a script to start my docker like this one:

docker run --name supercobbler --hostname supercobbler \
-d --privileged \
-v /sys/fs/cgroup:/sys/fs/cgroup:ro \
-p \
-p \
-p \
-p \

After that, provided my IP is visible from  my network, I get the cobbler web here:

IMPORTANT: it’s https. If you don’t go to https, you will get a Forbidden access message. The default user is cobbler, password cobbler. If you want to change that, it’s enough to type:

htdigest /etc/cobbler/users.digest "Cobbler" cobbler

after being connected to the docker:

 docker exec -it supercobbler /bin/bash

I must say the same docker runs, with a little variations, on my mac OS also. I tested it there. But that’s enough for today. I think I may write later, but not about dockers, I promise!