IRC Client: Irssi On Atomic Host

If you are a terminal geek you will always want to do things using terminal😉. And when it comes to Atomic host, YES you will have to do stuffs using terminal.

If you don’t know about Atomic, you must visit http://www.projectatomic.io:)

This post will describe how to setup and use IRC client on Atomic host. This will be applicable for any Cloud host also.

Irssi is a terminal based IRC client for Unix/Linux systems. And the best part is we will not need to setup things manually because we have containers:).

Let’s Get Stared:

I am using Fedora Atomic host here. Get Fedora atomic host from herehttps://getfedora.org/en/cloud/download/atomic.html

Make Sure you have Docker installed.

Copy the Dockerfile from here: https://github.com/trishnaguha/Fedora-Dockerfiles/blob/irssi/irssi/Dockerfile

Now run docker build -t username/irssi .This will build image.

There after you just need to run the container:)  docker run -it username/irssi.

Later on sometime you will be able to do the whole set up only docker run -it fedora/irssi once Fedora adds Irssi to its Docker hub :).

After you start the container you will see something like this:

Screenshot from 2016-08-19 14-12-05

Let’s join a channel

Screenshot from 2016-08-19 14-14-16

You will find the Irssi Commands here: Irssi Commands.

Cockpit Container on Atomic Host

Screenshot from 2016-08-16 17-42-05

Cockpit is a remote manager for GNU/Linux servers.

  • Cockpit is a server manager that makes it easy to administer your GNU/Linux servers via a web browser.
  • Cockpit makes it easy for any sysadmin to perform simple tasks, such as administering storage, inspecting journals and starting and stopping services.
  • Jumping between the terminal and the web tool is no problem. A service started via Cockpit can be stopped via the terminal. Likewise, if an error occurs in the terminal, it can be seen in the Cockpit journal interface.
  • You can monitor and administer several servers at the same time. Just add them with a single click and your machines will look after its buddies.

The Cockpit team is currently uploading the cockpit container to the Fedora repo on the Docker Hub, but Fedora Release Engineering is working on publishing layered images. We now have a super-privileged container (SPC) for the web service (cockpit-ws) with the bridge, shell, and docker components installed by default on the Atomic host.

This means you can simply run atomic run fedora/cockpitws as root or with sudo and cockpit will be running on port 9090. Try it:).

Getting Started

Boot up Fedora Atomic instance.

Install the Container

Install cockpitws container using atomic.

# atomic install fedora/cockpitws
/usr/bin/docker run -ti --rm --privileged -v /:/host fedora/cockpitws /container/atomic-install
+ sed -e /pam_selinux/d -e /pam_sepermit/d /etc/pam.d/cockpit
+ mkdir -p /host/etc/cockpit/ws-certs.d
+ chmod 755 /host/etc/cockpit/ws-certs.d
+ chown root:root /host/etc/cockpit/ws-certs.d
+ mkdir -p /host/var/lib/cockpit
+ chmod 775 /host/var/lib/cockpit
+ chown root:wheel /host/var/lib/cockpit
+ /bin/mount --bind /host/etc/cockpit /etc/cockpit
+ /usr/sbin/remotectl certificate --ensure

There’s a few things going on here in the install method.

Note that we’re exposing the Atomic host root directory to the container at /host. As a SPC (Super Privileged Container), this allows the container to access the host filesystem and make changes. The install method creates a set of directories in /etc and /var to persist configs. This means that we don’t need any particular cockpitws container to stick around, any cockpitws container will be able to read the appropriate state from the host. We can upgrade the cockpit image and not worry about losing data. Since/etc and /var are writable on an Atomic host, and /etc content will be appropriately merged on a tree change, cockpit data will also survive an atomic host upgrade as well.

Set up the systemd unit

# vi /etc/systemd/system/cockpitws.service

[Unit]
Description=Cockpit Web Interface
Requires=docker.service
After=docker.service

[Service]
Restart=on-failure
RestartSec=10
ExecStart=/usr/bin/docker run --rm --privileged --pid host -v /:/host --name %p fedora/cockpitws /container/atomic-run --local-ssh
ExecStop=-/usr/bin/docker stop -t 2 %p

[Install]
WantedBy=multi-user.target

With the container available to docker, we’ll build the systemd unit file next. For local systemd unit files, we want them to reside in /etc/systemd/system.

The ExecStart line in the unit file looks nearly identical to the RUN label, with one change. When running containers from systemd, we don’t want to use docker -d, instead we want either docker -a or docker --rm. We’re using docker --rm here since we don’t need this particular container instance to survice a restart. We are going to name container using the %p tag to pick up the systemd service name, just to make it easier to find in docker ps.

Start the Service

Now we can reload systemd to read the new unit file, enable the service to start on reboot, and then start the new cockpitws service.

  # systemctl daemon-reload
  # systemctl enable cockpitws.service
  Created symlink from /etc/systemd/system/multi-user.target.wants/cockpitws.service to /etc/systemd/system/cockpitws.service.
  # systemctl start cockpitws.service
  # systemctl status cockpitws.service

  ● cockpitws.service - Cockpit Web Interface
  Loaded: loaded (/etc/systemd/system/cockpitws.service; enabled; vendor preset: disabled)
  Active: active (running) since Tue 2016-08-16 12:42:23 UTC; 10s ago
Main PID: 2047 (docker)
   Tasks: 6 (limit: 512)
  Memory: 0B
     CPU: 1ms
  CGroup: /system.slice/cockpitws.service
          └─2047 /usr/bin/docker run --rm --privileged --pid host -v /:/host --name cockpitws fedora/cockpitws /container/atomic-run --local-ssh

  Aug 16 12:42:25 atomic.novalocal docker[2047]: + sed -e /pam_selinux/d -e /pam_sepermit/d /etc/pam.d/cockpit
  Aug 16 12:42:25 atomic.novalocal docker[2047]: + mkdir -p /host/etc/cockpit/ws-certs.d
  Aug 16 12:42:25 atomic.novalocal docker[2047]: + chmod 755 /host/etc/cockpit/ws-certs.d
  Aug 16 12:42:25 atomic.novalocal docker[2047]: + chown root:root /host/etc/cockpit/ws-certs.d
  Aug 16 12:42:25 atomic.novalocal docker[2047]: + mkdir -p /host/var/lib/cockpit
  Aug 16 12:42:25 atomic.novalocal docker[2047]: + chmod 775 /host/var/lib/cockpit
  Aug 16 12:42:25 atomic.novalocal docker[2047]: + chown root:wheel /host/var/lib/cockpit
  Aug 16 12:42:25 atomic.novalocal docker[2047]: + /bin/mount --bind /host/etc/cockpit /etc/cockpit
  Aug 16 12:42:25 atomic.novalocal docker[2047]: + /usr/sbin/remotectl certificate --ensure
  Aug 16 12:42:25 atomic.novalocal docker[2047]: INFO: cockpit-ws: Using certificate: /etc/cockpit/ws-certs.d/0-self-signed.cert

Now that the service is up and running, point your web browser at port 9090 on the Atomic host and you should see the Cockpit login page. You’ll need to log in with a user in the wheel group in order to administrate the system, but you can log in as any user to view the local host. For the published Fedora Atomic cloud image, log in with the fedora credentials and you should be ready to go. You can login as root user. For that You need to setup password for root user in your atomic instance. After that you need to change PasswordAuthentication to yes in /etc/ssh/sshd_config and you are ready to go.

You can add other hosts to this Cockpit instance, with the knowledge that reboots and upgrades to the host or the container won’t affect the configuration.

Note that if you are using Openstack you need to add Port 9090 in your security group.

I just started Cockpit container on atomic host yesterday.

Here is the screenshot of the containers running.

Screenshot from 2016-08-17 11-30-22

Getting Started with Atomic Commands

Project Atomic is a framework to create OS from RHEL, CentOS, Fedora and the aim of Project Atomic is to create better OS for containers.

Why Atomic?

  • For running containers we don’t need full fledged distribution.
  • Less number of packages to maintain

rpm-ostree is a software management tool that combines the features of both traditional RPMs and OSTree. we can be way more confident on updating system if we know that we can have reliable rollback even after updating system. It provides clear transaction for updates. Since the whole process is atomic there is almost no chance o half way update of the system hence less chance of breaking system.

The atomic command defines the entrypoint for Project Atomic hosts.

On Atomic hosts there are two software delivery vehicles:

  • rpm-ostree for managing deployment and updates of host system.
  • Docker to provide containers running services and applications.

RPM-OSTree makes the file-system immutable i.e, read only except var and etc. Docker uses /var/lib/docker where all the docker related files, images are stored. /etc has all the configuration files.

Atomic Command: Let’s get Started!

We will first need to have an atomic host running.

  • atomic host upgrade will upgrade to a newer version.
  • atomic host rollback will rollback to the previous version.
  • atomic host status displays the status of the atomic host installed.
  • atomic run <name> allows an image provider how a container image expects to be run.
  • atomic install <name> installs a container on atomic host with systemd unit file to run it as service.
  • atomic uninstall <name> uninstalls the container from atomic host.
  • atomic info <name> displays LABEL information of the image.
  • atomic images lists the container images on your Atomic host.

When we ship an application you need to run an install script. Using Atomic tool management system we can embed install and uninstall script within our application itself. In the Dockerfile of our application we need to have LABEL INSTALL that points to the docker command for the application with executable install script. When we execute atomic install it will specifically run LABEL INSTALL command from the Dockerfile to install the application on atomic host.
Same way to uninstall an application we need to run atomic uninstall that will specifically run LABEL UNINSTALL from Dockerfile which specifically points to the uninstall script for the application.

For further reading regarding Install and Uninstall: http://www.projectatomic.io/docs/usr-bin-atomic

Atomic Command Cheat Sheet is now available.

BeFunky Collage

Further Reading:

 

How to Convert NetworkManager to networkd

This post will describe how to convert NetworkManager to networkd.

I am using Fedora Workstation 24 image. If you are using fedora or projectatomic cloud images you can use networkd there.

Switching from NetworkManager to networkd:

We need to make sure that NetworkManager and networkd don’t start on reboot.

# systemctl disable NetworkManager
# systemctl disable network

Now Ensure that systemd-networkd starts on the next boot:

# systemctl enable systemd-networkd

Enable the resolver and make a symlink:

# systemctl enable systemd-resolved
# systemctl start systemd-resolved
# rm -f /etc/resolv.conf
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Configure your network interfaces in /etc/systemd/network and then reboot.

Some sample use cases for systemd-networkd and example configurations are below:

Simple DHCP on single interface

For an interface eth0, a single .network file is needed

# cat /etc/systemd/network/eth0.network
[Match]
Name=eth0

[Network]
DHCP=yes

Bridging

Here we have eth0 and we want to add it to a bridge. This could be handy for servers where you want to build containers or virtual machines and attach them to the network bridge.

We will start with setting up bridge interface br0.

# cat /etc/systemd/network/br0.netdev
[NetDev]
Name=br0
Kind=bridge

Let’s configure the network for the bridge

# cat /etc/systemd/network/br0.network
[Match]
Name=br0

[Network]
IPForward=yes
DHCP=yes

The IPForward=yes will take care of the systemctl forwarding setting for us (net.ipv4.conf.br0.forwarding = 1) automatically when the interface comes up.
Now take ethernet adapter and add it to bridge

# cat /etc/systemd/network/eth0.network
[Match]
Name=eth0

[Network]
Bridge=br0

Now reboot the system and it will come up with eth0 as a port on br0.

Bonding

Let’s configure a bonding interface which is similar to that of a bridge. Start by setting up individual network adapters.

# cat /etc/systemd/network/ens9f0.network
[Match]
Name=ens9f0
 
[Network]
Bond=bond1
# cat /etc/systemd/network/ens9f1.network
[Match]
Name=ens9f1

[Network]
Bond=bond1

Create network device for the bond

# /etc/systemd/network/bond1.netdev
[NetDev]
Name=bond1
Kind=bond

[Bond]
Mode=802.3ad
TransmitHashPolicy=layer3+4
MIIMonitorSec=1s
LACPTransmitRate=fast

Add networking to the device

# /etc/systemd/network/bond1.network
[Match]
Name=bond1
 
[Network]
DHCP=yes
BindCarrier=ens9f0 ens9f1

The BindCarrier is optional but recommended. It gives systemd-networkd the hint that if both bonded interfaces are offline, it should remove the bond configuration until one of the interfaces comes up again.

Check Status

Output from systemd-netword will appear in system journal. The networkctl command allows to check your network devices at a glance.

Here’s an example of the network setup we just created:

Screenshot from 2016-08-09 14-31-17

Further Reading: http://fedoracloud.readthedocs.io/en/latest/networkd.html

Fedora Women Day 2016

CnZe3pLUAAAwGrm (1)

Fedora Women Day is celebrated to raise awareness and bring Fedora women contributors together. This is a great time to network with other women in Fedora and talk about their contributions and work in Fedora Project.

The event was held at Netaji Subhash Engineering College (NSEC) in Kolkata, India on 15th July, 2016.

Fedora Women Day was also celebrated in Pune, India and Tirana, Albania. https://fedoraproject.org/wiki/Fedora_Women_Day_2016#Local_Events

The event started at 10:30 AM. Women started coming in and it was pretty nice crowd.

The event started with my talk. It was my first talk so I was really excited.

I talked about Fedora Women Day and the purpose. Then I started talking about the work I do in Fedora Project. Most of the part of my talk was regarding Fedora Infrastructure and Fedora Cloud.

Since my most of the contributions lie in Bodhi(Fedora Infrastructure) and Tunirtests(Fedora Cloud) so I specifically gave some insight on these projects. I explained the architecture of Bodhi and Tunirtests and how one can start contributing those specific projects.

I also shared my story on how I started contributing to Fedora Project.

Here is the slide of my talk: trishnaguha.github.io/trishnagslides-what-i-do-in-fedora-how-can-you-get-involved.html

After few hours of my talk I had to leave early for some urgent work. You will find the full event report here: Event Report.

I received Fedora stickers, F24 workstation DVD and Fedora T-shirt, but not sure I can put the T-shirt on, it seems so large😦.

Jpeg

A Moment to Cherish

It was June when I was interviewed by opensource.com for my Opensource (FOSS) journey and Summer training in Dgplug.

https://opensource.com/life/16/6/how-community-taught-me-code

Heartfelt Thanks to my family, mentors and friends I have come across so far!

Definitely a moment that I would love to cherish for lifelong:).

Contributions:  https://github.com/trishnaguha  https://pagure.io/user/trishnag

First Guest Session of DGPLUG Summer Training 2016

Screenshot from 2016-07-06 14-06-08

I never imagined that Kushal Das (Mentor of DGPLUG) would ask me to take the first guest session at DGPLUG summer training 2016. I was one of the participants of DGPLUG summer training 2015.

Few days ago I was asked to take the first guest session at DGPLUG summer training 2016 about my journey in FOSS, Python and DGPLUG. I became super excited after hearing that and also it was the first guest session of DGPLUG summer training 2016. It was really unexpected:). The next day I took the session at 18:30 IST on #dgplug channel on IRC.

I started with little introduction about me and let the participants ask Questions after that. The whole session went really interactive. They asked smart questions despite being newbies:).

The mostly asked Questions were How I started my first upstream contribution, How did I select the project I worked on for the first time, What do I do when I am stuck at an issue, How do I manage time to contribute along with my studies, How FOSS helps in career, Steps to contribute in a better way and all.

I really enjoyed answering all kind of Questions those were asked.

You can join the summer training still now. Join #dgplug channel on IRC and the Mailing list. Fill up the form and ping Kushal Das. Feel free to ask if you have any query on IRC or Mailing list. You get this golden opportunity only once a year, so don’t miss it.

The IRC logs are uploaded here. You will find all the conversations here https://dgplug.org/irclogs/2016/Logs-2016-07-01-15-00-trishna.txt.

It feels amazing to be a part of such a great community:).