After some great help and collaboration from all the colleagues reviewing, suggesting edits, we were able to prepare a blog post on Citellus, the tool we develop as part of our daily work solving cases.
Check it out at Citellus: System configuration validation tool
Enjoy!
Pablo
Click to read and post commentsI've got a slot at SuperSec 2018 (https://supersec.es/): Congress on secure software development, happening in Almería, Spain on the weekend on 12-13 May.
I'll be presenting on 13th may at 10:50, and the slide deck to be used is at https://github.com/citellusorg/citellus/blob/master/doc/supersec2018-presentation-ES.md and I'll be updating this once I get the recording URL.
Some data about the event:
About the topics, the main focus was security on software from design phase to production and maintenance.
Some of the presentations insisted on the costs not only for your brand, reputation or business damage, but also on the actual cost of fixing issues later on vs doing a secure development.
For the secure development approach, where most of the bugs are introduced and can be fixed for cheap, some tools were presented that help to early detect known coding mistakes, hilighting them in automated, and later, working on static code analysis and code review.
It was also interesting to see the EU focus via FOSSA-2 project to promote Open Source and hear about legal implications and intended roadmap for security in software, both for Spain and EU.
Common Criteria was also one of the topics as well as the code audits, penetration testing, etc (with over 20 slots you can imagine :) )
On our side, we were presenting about how Citellus can help in detecting current or future issues that affect your environment and how easily it can be extended to cover your use cases while contributing it back to community.
Of course we were also hilighting how collaboration got Citellus enhanced with feedback from RDO Project users to cover not only RHEL6 and RHEL7 but also Fedora, CentOS and other distributions via more generic tests and functios that covers them.
Enjoy!
PD: Hilighted in Citellus blog at https://citellus.org/blog/2018/04/16/supersec/
Click to read and post commentsAs hilighted in the prior edition of the 'What's new', we got a slot for DevConf.cz 2018.
During that slot, my colleagues Martin, Pablo and myself were presenting on the history and basics of Citellus and how it helps on debugging issues and providing faster analysis of already known ones.
It is possible to watch the recording at https://www.youtube.com/watch?v=SDzzqrUdn5A and the slides used at: https://github.com/citellusorg/citellus/blob/master/doc/devconfcz2018-presentation-revealmd.md
Hope you enjoy it!
Click to read and post commentsDuring recent weeks we've been coding and performing several changes to Citellus and Magui.
Checking the latest logs or list of issues open and closed on github is probably not an easy task or the best way to get 'up-to-date' with changes, so I'll try to compile a few here.
First of all, we're going to present it at Devconf.cz 2018, so come stop-by if assisting :-)
Some of the changes include...
--priocore extensionansible-playbook commandmagui.json (with ?json=magui.json) and show it's output.--web to automatically create the json named citellus.json on the folder specified with -o and copy the citellus.html file there. So if you provide sosreports over http, you can point to citellus.html to see graphical status! (check latest image at citellus website as www.png )
reboot.py that checks for unexpected rebootscitellus.json magui does load it to speed it up process across multiple sosreports.ansible-playbook to copy citellus program to remote host and run there the command, and bring back the generated citellus.json so you can quickly run citellus across several hosts without having to manually perform operations or generate sosreports.citellus-outputscitellus-metadatametadata plugins in citellus arranged by plugin and sosreportid to just work on the data they know how to processpipeline-yamlseqnoreleasequiet mode on the data received from citellus as well as local plugins, so only outputs with ERROR or different output on sosreports is shown, even on magui plugins.As you can see we've been busy trying to improve plugins, Citellus framework and Magui as well.
We've been also busy demonstrating to others it's value and raising lot of new issues and closing them with our commits (294 requests closed so far).
So, come and tell us what else are you missing or how can we improve it to suit your needs (or code them yourself and submit a review!)
Click to read and post commentsWhile working on Citellus and Magui it soon became evident that Unit testing for validating the changes was a requirement.
Initially, using a .travis.yml file contained in the repo and the free service provided by https://travis-ci.org we soon got https://github.com repo providing information about if the builds succeded or not.
When it was decided to move to https://gerrithub.io to work in a more similar way to what is being done in upstream, we improved on the code comenting (peer review), but we lost the ability to run the tests in an automated way until the change was merged into github.
After some research, it became more or less evident that another tool, like Jenkins was required to automate the UT process and report to individual reviews about the status.
Some initial steps are required for integration:
In order to setup the Jenkins environment a new VM was spawned in one of our RHV servers.
This VM was installed with:
RHEL7 provides a stable environment for run on, but at the same time we were lacking some of the latest tools we're using for the builds.
As a dirty hack, it was altered in what is not a recomended way, but helped to quickly check as proof of concept if it would work or not.
Once OS was installed, some commands (do not run in production) were used:
pip install pip # to upgrade pip
pip install -U tox # To upgrade to 2.x version
# Install python 3.5 on the system
yum -y install openssl-devel gcc
wget https://www.python.org/ftp/python/3.5.0/Python-3.5.0.tgz
tar xvzf Python-3.5-0.tgz
cd Python*
./configure
# This will install in alternate folder in system not to replace user-wide python version
make altinstall
# this is required to later allow tox to find the command as 'jenkins' user
ln -s /usr/local/bin/python3.5 /usr/bin/
For the jenkins installation it's easier, there's a 'stable' repo for RHEL and the procedure is documented:
wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat-stable/jenkins.repo
rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key
yum install jenkins java
chkconfig jenkins on
service jenkins start
firewall-cmd --zone=public --add-port=8080/tcp --permanent
firewall-cmd --zone=public --add-service=http --permanent
firewall-cmd --reload
This will install and start jenkins and enable the firewall to access it.
If you can get to the url of your server at the port 8080, you'll be presented an initial procedure for installing Jenkins.
During it, you'll be asked for a password on a file on disk and you'll be prompted to create an user we'll be using from now on to configure.
Also, we'll be offered to deploy the most common set of plugins, choose that option, and later we'll add the gerrit plugin and Python.
Once we can login into gerrit, we need to enter the administration area, and install new plugins and install Gerrit Trigger.
Above link details how to do most of the setup, in this case, for gerrithub, we required:
Once done, click on Test Connection and validate if it worked.
At the time of this writing, version reported by plugin was 2.13.6-3044-g7e9c06d when connected to gerrithub.io.
Now, we need to create a Job (first option in Jenkins list of jobs).
**import os
import tox
os.chdir(os.getenv('WORKSPACE'))
# environment is selected by ``TOXENV`` env variable
tox.cmdline()
From this point, any new push (review) made against gerrit will trigger a Jenkins build (in this case, running tox). Additionally, a manual trigger of the job can be executed to validate the behavior.
In our project, tox checks some UT's on python 2.7, and python 3.5, as well as python's PEP compliance.
Now, Jenkins will build, and post messages on the review, stating that the build has started and the results of it, setting also the 'Verified' flag.
Enjoy having automated validation of new reviews before accepting them into your code!