Today I built and pushed the Tor RPM(s) for 0.4.7.11. Please make sure that you upgrade your relays and bridges. I have the updated package for Fedora 37 too (which also released today).
You can know more about the Tor's RPM respository at https://support.torproject.org/rpm/.
If you have any queries, feel free to find us over #tor or #tor-relay channel on OFTC.
Last night I built and pushed the Tor RPM(s) for 0.4.7.8. This is a security update, so please make sure that you upgrade your relays and bridges.
You can know more about the Tor's RPM respository at https://support.torproject.org/rpm/
If you have any queries, feel free to find us over #tor channel on OFTC.
Now we have official Tor RPM repositories for Fedora, CentOS/RHEL. The support documentation is already in place.
Using this repository, you can get the latest Tor build for your distribution from the upstream project itself. Tor already provides similar packages for Debian/Ubuntu systems.
Add the following to the /etc/yum.repos.d/tor.repo.
[tor]
name=Tor for Fedora $releasever - $basearch
baseurl=https://rpm.torproject.org/fedora/$releasever/$basearch
enabled=1
gpgcheck=1
gpgkey=https://rpm.torproject.org/fedora/public_gpg.key
cost=100
Then you can install the package via regular dnf command.
$ sudo dnf install tor
You will have to import the new keys used for signing these packages.
Importing GPG key 0x3621CD35:
Userid : "Kushal Das (RPM Signing key) <kushal@torproject.org>"
Fingerprint: 999E C8E3 14BC 8D46 022D 6C7D E217 C30C 3621 CD35
From : https://rpm.torproject.org/fedora/public_gpg.key
Is this ok [y/N]: y
If you run a Tor relay (which you all should, one of the easiest ways to contribute to the project and help people worldwide) on CentOS/RHEL, you can use similar repository configuration.
In 2017, I started working on a new book to teach Linux command line in our online summer training. The goal was to have the basics covered in the book, and the same time not to try to explain things which can be learned better via man pages (yes, we encourage people to read man pages).
This one question always came up, many times, the students managed to destroy
their systems by doing random things. rm -rf is always one of the various
commands in this regard.
Now, the book has a new chapter, LYM Workbook, where the reader can set up VMs in the local machine via Vagrant, and go through a series of problems in those machines. One can then verify if the solution they worked on is correct or not. For example:
sudo lymsetup copypaste
sudo lymverify copypaste
We are starting with only a few problems, but I (and a group of volunteers) will slowly add many more problems. We will also increase the complexity by increasing the number of machines and having setup more difficult systems. This will include the basic system administration related tasks.
Have a look at the issues,
feel free to pick up any open issue or create issues with various problems
which you think are good to learn. Things can be as easy as rsync a
directory to another system, or setting up Tor
Project and use it as a system proxy.
Just adding one problem as an issue is also a big help, so please spend 5 minutes of your free time, and add any problem you like.
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.
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/
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.
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.
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.
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.
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.
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
The next meeting is in next week at the same time. See you all there.
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.
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.
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.
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 :)
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.
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.