Kushal Das4

FOSS and life. Kushal Das talks here.

kushal76uaid62oup5774umh654scnu5dwzh4u2534qxhcbi4wbab3ad.onion

Introducing rpm-macros-virtualenv 0.0.1

Let me introduce rpm-macros-virtualenv 0.0.1 to you all.

This is a small set of RPM macros, which can be used by the spec files to build and package any Python application along with a virtualenv. Thus, removing the need of installing all dependencies via dnf/rpm repository. One of the biggest usecase will be to help to install latest application code and all the latest dependencies into a virtualenv and also package the whole virtualenv into the RPM package.

This will be useful for any third part vendor/ISV, who would want to package their Python application for Fedora/RHEL/CentOS along with the dependencies. But, remember not to use this for any package inside of Fedora land as this does not follow the Fedora packaging guidelines.

This is the very initial release, and it will get a lot of updates in the coming months. The project idea is also not new, Debian already has dh-virtualenv doing this for a long time.

How to install?

I will be building an rpm package, for now download the source code and the detached signature to verify it against my GPG key.

wget https://kushaldas.in/packages/rpm-macros-virtualenv-0.0.1.tar.gz
wget https://kushaldas.in/packages/rpm-macros-virtualenv-0.0.1.tar.gz.asc
gpg2 --verify rpm-macros-virtualenv-0.0.1.tar.gz.asc rpm-macros-virtualenv-0.0.1.tar.gz

Untar the directory, and then copy the macros.python-virtualenv file to the RPM macros directory in your system.

tar -xvf rpm-macros-virtualenv-0.0.1.tar.gz
cd rpm-macros-virtualenv-0.0.1/
sudo cp macros.python-virtualenv /usr/lib/rpm/macros.d/

How to use?

Here is a minimal example.

# Fedora 27 and newer, no need to build the debug package
%if 0%{?fedora} >= 27 || 0%{?rhel} >= 8
%global debug_package %{nil}
%endif
# Use our interpreter for brp-python-bytecompile script
%global __python /opt/venvs/%{name}/bin/python3


%prep
%setup -q

%build
%pyvenv_create
%{__pyvenvpip3} install --upgrade pip
%pyvenv_build

%install
%pyvenv_create
%{__pyvenvpip3} install --upgrade pip
%pyvenv_install
ln -s /opt/venvs/%{name}/bin/examplecommand $RPM_BUILD_ROOT%{_bindir}/examplecommand

%files
%doc README.md LICENSE
/opt/venvs/%{name}/*

As you can see, in both %build and in %install, first we have to call %pyvenv_install, that will create our virtualenv. Then we are installing the latest pip in that environment.

Then in the %build, we are calling %pyvenv_build to create the wheel.

In the %install section, we are calling %pyvenv_install macro to install the project, this command will also install all the required dependencies (from the requirements.txt of the project) by downloading them from https://pypi.org.

If you have any command/executable which gets installed in the virtualenv, you should create a symlink to that from $RPM_BUILD_ROOT/usr/bin/ directory in the %install section.

Now, I have an example in the git repository, where I have taken the Ansible 2.7.1 spec file from Fedora, and converted it to these macros. I have build the package for Fedora 25 to verify that this works.

Running Tor relay inside a docker container

The latest Tor project release is 0.3.2.10. But, that is not available on all the different versions of different Linux distributions. For example, CentOS 7 has tor-0.2.9.14-1.el7, and only Fedora 28 has the latest Tor.

This is where a container can help. The official builds from Tor Project are for Debian, means we can build and use a Debian based container.

The Dockerfile

FROM debian:stretch
LABEL MAINTAINER Kushal Das <mail@kushaldas.in>

RUN apt-get update
RUN apt install vim gpg -y


RUN echo "deb http://deb.torproject.org/torproject.org stretch main\ndeb-src http://deb.torproject.org/torproject.org stretch main" > /etc/apt/sources.list.d/tor.list

# Let us get the key for Tor
RUN gpg --keyserver keys.gnupg.net --recv A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89
RUN gpg --export A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89 > tor.gpg
RUN apt-key add tor.gpg

# Finally install Tor
RUN apt update
RUN apt install tor deb.torproject.org-keyring -y
ADD ./torrc /etc/tor/torrc

# Add the tor user
RUN groupadd -g 1000 tor && useradd -m -d /home/tor -g 1000 tor


# Now drop to the actual user
USER tor
RUN mkdir -p /home/tor/.tor/keys

VOLUME ["/home/tor/.tor"]

EXPOSE 9001 9051

ENTRYPOINT ["tor"]

I have a configuration file named torrc, you can copy the sample configuration and edit as required. I have the following entries there.

SOCKSPort 0

ORPort 9001

Nickname NICKNAME_FOR_THE_RELAY

ContactInfo  <YOUR_EMAIL_ADDRESS>

ExitRelay 0

Next, we will create a directory in the host system to keep the keys, and other files. We want to restart the container and still have the same details, mounting a directory from the host system into the container will help us in that.

mkdir /mnt/tor
chcon -R -t svirt_sandbox_file_t /mnt/tor

Please also make sure that you have correct ownership of that directory.

Running the container

docker run -d -v /etc/localtime:/etc/localtime -v /mnt/tor:/home/tor/.tor --restart always -p 9001:9001 -name relay kushaldas/tor:0.3.2.10

After starting the container, you can check the logs for any error. If you can see the following message in the log, then it means that you configured the relay properly.

# docker logs -f relay

Self-testing indicates your ORPort is reachable from the outside.

The official relay guide

Tor project recently published an updated relay guide for anyone new to running a relay. Please go through that document first. If you need help, there is a mailing list of Tor relay operators, and #tor channel on OFTC IRC server is also very welcoming.

Updates from CentOS Cloud SIG

Back in 2014 we started working on CentOS Cloud SIG. This SIG started with focus on packaging, and maintaining different FOSS IaaS platforms. We are not a vendor specific group, means anyone who wants to keep their cloud project maintained in the CentOS ecosystem, are very welcome to join, and work in this SIG.

We have our regular IRC meeting on every Thursday at 15:00 UTC in the #centos-devel IRC channel on freenode. The regular meeting agenda is kept updated on a etherpad. The major points from this week’s meeting are

  • We have an upcoming RDO test day on 10th March. More details are on this blog post.
  • There will be a live demo about TripleO, you can view it on 9th March in youtube.
  • OpenNebula folks were missing from the meeting, but we remember that they need more help in porting the required packages. So, if you want to start contributing OpenNebula or CentOS this can be your chance :)

The next meeting is in next week at the same time. See you all there.

Tunir 0.13 is released and one year of development

Tunir 0.13 release is out. I already have a koji build in place for F23. There are two major feature updates in this release.

AWS support

Yes, we now support testing on AWS EC2. You will have to provide your access tokens in the job configuration along with the required AMI details. Tunir will boot up the instance, will run the tests, and then destroy the instance. There is documentation explaining the configuration details.

CentOS images

We now also support CentOS cloud images, and Vagrant images in Tunir. You can run the same tests on the CentOS images based on your need.

One year of development

I have started Tunir on Jan 12 2015, means it got more than one year of development history. At the beginning it was just a project to help me out with Fedora Cloud image testing. But it grew to a point where it is being used as the Autocloud backend to test Fedora Cloud, and Vagrant images. We will soon start testing the Fedora AMI(s) too using the same. Within this one year, there were total 7 contributors to the project. In total we are around 1k lines of Python code. I am personally using Tunir for various other projects too. One funny thing from the code commits timings, no commit on Sundays :)

Meeting agenda

The above is a real life experience in one of the company I worked for. You can imagine what all the Engineers were thinking. Those meetings were couple of hours long, and really boring.

In the community based IRC meetings, it is generally the opposite. Many meetings I attend already use a ticketing system (like Trac) to track the meeting agenda, or even use something like Gobby to keep the agenda. Others can join the session, and edit the agenda as required.

We now have defined meeting agenda for CentOS Cloud SIG. Feel free to add items to the list which will be discussed in the next meeting. CentOS Cloud SIG (CCS) is a group of people coming together to focus on packaging and maintaining different FOSS based Private cloud infrastructure applications that one can install and run natively on CentOS.

CentOS Cloud SIG update

For the last few months we are working on the Cloud Special Interest Group in the CentOS project. The goal of this SIG is to provide the basic guidelines and infrastructure required of FOSS cloud infrastructure projects so that we can build and maintain the packages inside official CentOS repositories.

We have regular meetings at 1500 UTC in every Thursday on #centos-devel IRC channel. You can find the last week’s meeting log here. RDO (Openstack), Opennebula and Eucalyptus were the first few projects to come ahead, and participate in forming the SIG. We also have a good number of overlap with the Fedora Cloud SIG.

RDO is almost ready to do a formal release of Kilo on CentOS 7. The packages are in testing phase. Opennebula team has started the process to get the required packages built on CBS.

If you want to help feel free to join in the #centos-devel channel, and give us a shout. We do need more helping hands to package, and maintain various FOSS Cloud platforms.

There are also two GSoC projects under CentOS which are related to the Cloud SIG. The first one is “Cloud in a box”, and the second one is “Lightweight Cloud Instance Contextualization Tool”. Rich Bowen, and Haikel Guemar are the respective mentors for the projects.