Ιστολόγιο

After a few months of a lot of hard work, I’m thrilled to announce the availability of the Portage Puppet module version 2.0!

Background

This module was initally developed by Lance Albertson and some other guys from OSUOSL. Adrien Thebo, who by the way works for PuppetLabs, stepped in after some time and did some cleanup in the native types/providers that were included in there, and later he took over completely. Judging from the commit log though, the module was not getting the love it deserved

Meanwhile, we, the Gentoo Infrastructure team, decided to migrate from Cfengine 2 to Puppet. So I started digging around to check about Gentoo support in Puppet. Given the complexity of the package management in Gentoo, I didn’t have high expectations, and I wasn’t wrong. The internal Puppet Portage provider has pretty basic support, so I had to get my hands dirty and write something decent. Then I stumbled upon Adrien’s puppet-portage repo, which made me felt like I hit the jackpot. I started testing it to understand the functionality it covers, and meanwhile I spent some time reading books and experimenting with Puppet and Ruby, as both of them were pretty new to me.

Right after the Gentoo Miniconf I finally contacted Adrien and expressed my interest in developing more functionality to the module. In 3 – 4 months of hard work we managed to have all the functionality I had in mind, which is impressive. It was a great journey, as I had the chance to do quite some stuff in a technology that was completely unknown to me. Adrien was very helpful in giving me correct directions, and I even managed to write a native type and provider from scratch! Thanks a lot Adrien!

Special thanks also to Zac Medico, main Portage developer, for all his valuable input.

Features

Let’s see all the functionality this module provides. Most of the info below is stolen from the README file.

1) /etc/portage/package.*/*

There is a set of native providers that add support of handling entries for
/etc/portage/package.keywords, /etc/portage/package.use, /etc/portage/package.mask, /etc/portage/package.unmask. Examples:

package_use { 'app-admin/puppet': use => ['flag1', 'flag2'], target => 'puppet-flags', version => '>=3.0.1', ensure => present, }

“$use” can be either a string or an array of strings.

package_keywords { 'app-admin/puppet': keywords => ['~x86', '-hppa'], target => 'puppet', version => '>=3.0.1', ensure => present, }

“$keywords” can be either a string or an array of strings.

package_unmask { 'app-admin/puppet': target => 'puppet', version => '>=3.0.1', ensure => present, } package_mask { 'app-admin/puppet': target => 'tree', version => '>=3.0.1', ensure => present, }

A few issues for the above providers (all the issues are reported in the repo’s Github tracker, but we decided to leave them for the next milestone)

• Renaming the target leaves an empty file behind
• Wrong permissions in package.*/* files: This is actually solved for newly created files, we need to find a way to enforce sane permissions to all files under /etc/portage though
• Trigger rebuild after package_* addition/edit: The portage_* providers don’t trigger rebuild, but portage::package (which is described below) does trigger proper rebuilds
• package_* should always use default values when their attributes are not explicitly specified
• package_* types do not update version when it was not initially defined
• integration tests need to cover the cases of adding removing attributes: Those last three issues are related
• Automatically convert old package.* files to dirs: This is probably not going to be fixed. In short, the Portage module works only if /etc/portage/package.* are directories. If any of those is a file, it will print an error. For now you should convert any package.* files there to directories manually. A bash script to do it quickly:

for target in keywords use mask unmask; do if [[ -f /etc/portage/package.$target ]]; then mv /etc/portage/package.$target /etc/portage/package.${target}_bak mkdir /etc/portage/package.$target mv /etc/portage/package.${target}_bak /etc/portage/package.$target/old fi done

2) make.conf

NOTE: Be aware that make.conf has changed location, from /etc/make.conf to /etc/portage/make.conf. Make sure to update your systems as well. It’s new location makes much more sense. The Portage module uses by default the new location by default.

The Portage module provides a custom class to handle your entries in make.conf. Example:

portage::makeconf { 'use': content => 'flag1 flag2 flag3' }

This entry will also trigger rebuild of the affected packages.

portage::makeconf { 'gentoo_mirrors': content => 'url1 url2' }

As stated in issue #56, in a later milestone we will convert this class to a native type/provider, in order to make it more powerful.

3) portage::package

This is another custom class, which acts as a wrapper to the native package resource of Puppet. The following example sums up pretty much all of its functionality:

portage::package { 'app-admin/puppet': use => ['-minimal', 'augeas'], use_version => '>=3.0.1', keywords => ['~amd64', '~x86'], keywords_version => '>=3.0.1', mask => '<=2.3.17', unmask => '>=3.0.1', target => 'puppet', target_keywords => 'puppet-keywords', ensure => '3.0.1', }

• If no $target_{keywords,use,mask,unmask} is specified, then the value of $target is being used.
• The variables keywords, mask and unmask also accept the special value ‘all’, that will create versionless entries. (This applies only to portage::package, if you want versionless entries in any of the above package_* types, you can just omit the version attribute.)
• Any change in portage::package will also trigger the appropriate re-emerge to the affected package.

This class was my ultimate functionality request for Portage support in Puppet generally, thus it’s the part I’ve spent most of my time on.

4) Facts

All make.conf variables and most of the eselect modules are shown by facter:

... eselect_profile => hardened/linux/amd64 eselect_python => python3.2 eselect_ruby => ruby19 ... portage_portage_tmpdir => /var/tmp portage_portdir => /usr/portage portage_python_single_target => python2_7 portage_python_targets => python2_7 python3_2 portage_ruby_targets => ruby19 portage_sync => rsync://rsync.gentoo.org/gentoo-portage ...

Keep in mind though that some of the eselect modules are not being shown as facts on purpose. The reason is that either they are not useful, or they produce too complex output that needs further investigation on how to implement. The blacklisted eselect modules are ‘help’, ‘usage’, ‘version’, ‘bashcomp’, ‘env’, ‘fontconfig’, ‘modules’, ‘news’ and ‘rc’.

5) eselect

The eselect type/provider checks for the current state of an eselect module by reading the variable of the equivalent fact. Examples:

eselect { 'ruby': set => 'ruby19', }

For eselect modules that have submodules (eg php):

eselect { 'php_apache2': set => 'php5.3', }

This pretty much covers everything. I hope it will be useful for the community. Feel free to submit bugs, patches or ideas at the repo’s Github issue tracker.

In a try to revive the Gentoo Bugday I wrote this article in order to give some guide lines and encourage both users and developers to join. I think it would be great to get this event back and collaborate. Of course everyone can open/close bugs silently but this type of event is a good way to close bugs, attract new developers/users and improve community relations.  There is no need to be a Gentoo expert.  So I will give you some information about the event.

About:

Bugday is a monthly online event that takes place every first Saturday of every month  in #gentoo-bugs in the Freenode network. Its goal is to have users and developers collaborate  to close/open bugs, update current packages and improve documentation.

Location:

Gentoo Bugday take place in our official IRC channel #gentoo-bugs @ Freenode.  You can talk about almost everything. Your ebuilds, version bumps, bugs that you will choose to fix, etc.. This is a 24h event, so don’t worry about the timezone difference.

Requirements:

1. A Gentoo installation (real hardware) or in a Virtual Machine.
2. IRC Client to join #gentoo-bugs , #gentoo-dev-help (ebuild help) and #gentoo-wiki (wiki help)
3. Bugzilla account.
4. Positive energy / Will to help.
5. (bonus): Coffee

Goals:

1. Improve quality of Bugzilla
2. Improve Wiki’s documentation.
3. Improve community relations.
4. Attract new developers and users.
5. Promote Gentoo.

Tasks:

1. Fix bugs (users/developers)
2. Triage incoming bugs (users/developers) (Good to start!)
3. Version bumps (users/developers) ( Good to start!)
4. Improve wiki’s articles(users/developers) (Good to start!)
5. Add new wiki’s articles(users/developers)
6. Close old fixed bugs (developers-only)

A good way to start is to take a look at the ‘maintainer-needed‘ list . In addtion try picking up a bug from maintainer-wanted alias  at Bugzilla.

TIP: You should DOUBLE/TRIPLE check everything before submit a new bug/patch/ebuild.

TIP2: Please avoid 0day bump requests.

And do not forget every day is a bugday!!

Organize your schedule and join us every first Saturday of every month @ #gentoo-bugs.

Consider starting from today reading the following docs in order to help you.

Useful Docs:

1. Gentoo Bugday
2. Get Involved in Gentoo Linux
3. How to contribute to Gentoo
4. Gentoo Dev Manual
5. Contributing Ebuilds
6. Gentoo Bug Reporting Guide
7. Beautiful bug reports
8. Gentoo’s Bugzilla User’s Guide
9. How to get meaningful backtraces in Gentoo
10. The Basics of Autotools

I had this post in the Drafts for a while, but now it’s time to publish it since the situation does not seem to be improving at all.

As you probably now, if you want to become a Gentoo developer, you need to find yourself a mentor[1]. This used to be easy. I mean, all you had to do was to contact the teams you were interested in contributing as a developer and then one of the team members would step up and help you with your quizzes. However, lately, I find myself in the weird situation of having to become a mentor myself because potential recruits come back to recruiters and say that they could not find someone from the teams to help them. This is sub-optimal  for a couple of reasons. First of all, time constrains  Mentoring someone can take days, weeks or months. Recruiting someone after being trained (properly or not), can also take days, weeks or months. So somehow, I ended up spending twice as much time as I used to.  So we are back to those good old days, where someone needed to wait months before we fully recruit him. Secondly, a mentor and a recruiter should be different persons. This is necessary for recruits to gain a wider and more efficient training as different people will focus on different areas during this training period.

One may wonder, why teams are not willing to spend time to train new developers. I guess, this is because training people takes quite a lot of someone’s time and people tend to prefer fixing bugs and writing code than spending time training people. Another reason could be that teams are short on manpower, so try are mostly busy with other stuff and they just can’t do both at the same time. Others just don’t feel ready to become mentors which is rather weird because every developer was once a mentee. So it’s not like they haven’t done something similar before. Truth is that this seems to be a vicious circle. No manpower to train people -> less people are trained -> Not enough manpower in the teams.

In my opinion, getting more people on board is absolutely crucial for Gentoo. I strongly believe that people must spend time training new people because a) They could offload work to them ;) and b) it’s a bit sad to have quite a few interested and motivated people out there and not spend time to train them properly and get them on board. I sincerely hope this is a temporary situation and things will become better in the future.

ps: I will be in FOSDEM this weekend. If you are there and you would like to discuss about the Gentoo recruitment process or anything else, come and find me ;)

 

[1] http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=1&chap=2#doc_chap3

When you work with Django and especially with static files or other template tags you realize that you have to include {% load staticfiles %} in all our template files. This violates the DRY principle because we have to repeat the {% load staticfiles %} template tag on each template file .

Lets give an example.

We have a base.html file which links some Javascript and CSS files from our static folder.

{% load staticfiles %} <!DOCTYPE html> <html> <head> <title>Webapp</title> <link rel="stylesheet" type="text/css" href="{% static "css/random-css.css" %}"> <script type="text/javascript" src="{% static "js/random-javascript.js" %}"></script> {% block extra_js_top %}{% endblock %} </head> ... </html>

Also we have index.html which extends base.html and in addition it loads some extra javascript.

{% extends "base.html" %} {% load staticfiles %} {% block extra_js_top %} <script type="text/javascript" src="{% static "js/extra-javascript.js" %}"></script> {% endblock %}

As you can see I load again staticfiles in index.html. If I remove it, I will take this error. “TemplateSyntaxError at /, Invalid block tag ‘static’”. Unfortunately even if we extend base.html it will not inherit load template tag from the file and it will not load staticfiles to index.html that means it will not load our extra javascript file.
The truth is that there is a hack-y way to do that. After a small research I finally found a way to follow DRY principle and avoid repeating {% load staticfiles %} template tag in every template file.

Open one of the files that loads automatically from the beginning( settings.py, urls.py and models.py ). I will use settings.py.
So we add the following to settings.py:

from django import template   #django-staticfiles DRY principle template.add_to_builtins('django.contrib.staticfiles.templatetags.staticfiles')

With that snippet of code we load statcifiles “globally” and we don’t have to load staticfiles for every template (not even in base.html) because it loads from the beginning.

PS: Sometimes on big projects this way maybe will not be so ‘correct’ or considered unconventional technique and complicate the developers.

I hope it will be useful.

Happy django-ing.

Further reading:

• Template Inheritance
• Built-in template tags and filters
• Custom template tags and filter

Nowadays I see lots of new blog posts about how to contribute in open source projects and I decided to write a blog post about how to contribute to Gentoo Linux and become a vital part of the project.

My colleagues at university everytime we talk about Gentoo tell me that they cannot install Gentoo because it is too difficult for them or they are not ready to install it and configure it because they don’t have the experience and they finally give up.  Also some other colleagues tell me that they want to contribute to Gentoo and they don’t know how to start. Thats why I wrote this blogpost in order to give some guidelines for those who want to contribute.

In order to help and contribute in Gentoo you don’t have to know to code or to be a super duper Linux guru. Of course code/programming is the core of  open source projects but there are ways to contribute without knowing to code. Requirements are two things. A Gentoo installation and will to help.

Community

Gentoo like the rest FOSS Projects is based on volunteer efforts. The pylons of every FOSS project is its community. Without its community Gentoo wouldn’t exist. Even if someone doesn’t know to code, can contribute and learn from project’s community.

Forums:  Join our forums and help other users with their problem. It is a good opportunity also to learn more things about Gentoo.

Mailing Lists: Subscribe to our mailing lists and learn about the latest community and development news  of the project. Everyone can also help users to related mailing lists or discuss with Gentoo developers.

IRC: Join in our IRC channels. Help new users with their issues. Discuss with users and developers and express your opinion about the new features and the technical issues of the project. Make sure you will read our Code of Conduct first.

Planets: Follow our planet and watch some Gentoo-stuff blog posts from developers about Gentoo. There are interesting conversations (via comments) after the blog post between the users and the developers.

Promote: After you get some experience with the project promote your favourite distro( Gentoo of course ) writing blog posts and articles in forums and sites related to open source.  You can also spread the word in your local linux users group and at your university.

Participate in Events: Every month there are meetings from the most of the Gentoo project teams. The meetings take place at #gentoo-meetings. There is an ‘open floor’ at the end of the meeting where users can express their opinion.

Documentation

Gentoo has always been known for its wide variety and quality of documentation. It covers lots of aspect of Linux. Topics about desktop, software, security and most of them are not totally Gentoo based.  That’s the reason Gentoo documentation is successful and that’s why users from other Linux distributions using it. So you can be a part of this effort and improve the documentation.

Wiki:  Wiki is our fresh project. There are lots of ways to help here. Add new articles about the topics  you would like to see ( and have knowledge of them of course) and want to share it with the other Gentoo users. Improving and expanding wiki articles is a good way to help the project (avoid copy paste from other sources in the net). All users are encouraged to help, wiki is open for everyone. Use it responsibly because your posts will affect the Gentoo users who will try to follow your guide.

Translations: If English is not your native language translating wiki/documentation will be a very good way to help users that don’t know English and want to join to the community. Translations is a good way to contribute and expand the Gentoo community.

(bonus) Write article to your blog: If you find a configuration or a tool  or a new solution to a problem that saved your life at the Gentoo world. Don’t be afraid and share it with the other users.

Development ( Code )

As I said code is the core of any software project.  So if you have some knowledge with shell scripts and programming you are welcome to join the team. With small steps you can gain more experience with the project and contribute to it with your features and patches.

Bugs: Every FOSS project has its own bug tracking system, Gentoo as well has its own Bugzilla. There we report our issues. Build and run time failures , kernel problems ,  Gentoo tools issues,  stable requests.  You can also start contributing by confirming and reproducing bugs  and then try to offer solutions and fix the bugs( patches are welcome ). So feel free to  report new bugs to our Bugzilla. In addition there are requests to add or update(version bump*) ebuilds. Instead of requesting new ebuilds  and version bumps you can also write and  submit your ebuilds to our Bugzilla in order to be added to the Portage tree by a Gentoo developer.  Try picking up a bug from maintainer-wanted alias. If you need a review for your ebuild #gentoo-dev-help is the right place to do it.

* Please avoid 0day bump requests.

Arch Tester: An Arch Tester (a.k.a AT) is a trustworthy user capable of testing an application to determine its stability. Arch Testers should have a good understanding on how ebuilds works, bash scripting and should test lots of packages to their arch. You can become an AT at x86 and amd64 archs. Requirement is to have a stable Gentoo box. Your goal will be to test and install packages from the testing arch (~arch) and see if they are working in the stable arch. Then you can open a stabilization request to Bugzilla.

Sunrise Project: Sunrise is a starting point for gentoo users to contribute. The Sunrise team encourage users to write ebuilds and make sure that they follow Gentoo QA standards. Sunrise’s goal is to allow non-developers to maintain them. For questions you can ask at #gentoo-sunrise at Freenode.

Proxy-maintaining: The goal of this team is to maintain abandoned (orphaned) packages in order to prevent treecleaners from removing those packages.  Pick up some packages from the maintainer-needed list a begin to maintain it. For questions you can join #gentoo-dev-help.

Bugday: Bugday is an event which take place at #gentoo-bugs at Freenode every first weekend of every month. You can join and pick a bug and fix it. But have in mind that every day is a bugday so it doesn’t have to be a bugday to add your ebuild and fix bugs.

Advanced Community Projects: Portage, Gentoolkit,  Portage tools,  Kernel team, Infrastructure team, Security team and Hardened team. These projects are very special and important to the Gentoo so it is necessary to have a good level of knowledge in order to contribute to them. So if you have the skills join the party . 

Become a developer:  After you reach a good amount of contribution and you think you can be an active and vital member of the project you can start the process of becoming a developer. Talk to a Gentoo developer in order to mentor you and help you fill the ebuild and staff quiz and then the process of the recruiting will be completed with a live interview with a recruiter.

There are lots of  Gentoo project teams that need new members and help . Everyone can contribute to Gentoo either knowing to code or not. Every piece of help is useful for the project.

I think I covered the biggest part of the Gentoo and how to contribute to it . I’ll wait for your comments, if you think I missed something inform me. Fixes always welcome.

Start contributing from today.

Gentoo: If it moves, compile it

Further reading:

1. Gentoo Handbook
2. Gentoo Development Guide
3. Gentoo Projects Listing
4. Benefits of Gentoo
5. Easy way to assist us  by Markos Chandras
6. How to contribute to Gentoo
7. Beautiful bug reports
8. Sunrise Project ( lots of good tutorials inside )
9. Always looking for Arch Testers by Agostino Sarubbo

Following my recent recruitment performance post, here comes the second part of my Gentoo Miniconf 2012 presentation. The following two graphs aim to demonstrate the performance of proxy-maintainers aka, how Gentoo users help us improve and push new ebuilds to the portage tree

One can notice the increased number of maintainer-needed@ packages but this is because we “retired” a lot of inactive developers in the last 2 months. I expect this number to not increase further in the near future.

I would like to thank all of you who are actively participating in this team. Keep up the good work!

After one month I think it was time to write my review about Gentoo miniconf.

In 20 and 21 October I attended to the Gentoo Miniconf which was a part of the bootstrapping-awesome project, 4 conferences (openSUSE Conference/Gentoo Miniconf/LinuxDays/SUSE Labs)  where took place in the Technical Czech University at Prague.

Photo by Martin Stehno

Day 0: After our flight arrived in Prague’s airport – we went straight to the pre-conference welcome party in a cafe near the university where the conference took place. There we met the other greeks who arrived in the previous days and I had also the chance to meet a lot of Gentoo developers and talk with them.

Day 1: The first day started earlier in the morning. Me and Dimitris went to the venue before the conference started in order to prepare the room for the miniconf. The day started with Theo as host to welcome us. There were plenty of interesting presentations  that covered a lot of aspects of Gentoo, the Trustees/Council, Public Relations, The Gentoo KDE team, Gentoo Prefix, Security, Catalyst and Benchmarking. The highlight of the day was when Robin Johnson introduced the Infrastructure team and started a very interesting BoF which talked about the state of the Infra team, currently running web apps and the burning issue of the git migration. The first day ended with lots of beers in the big party of the conference in the center of the Prague next to the famous Charles Bridge.

Gentoo Developers group photo
Photo by Jorge Manuel B. S. Vicetto

 

Day 2:The second day was more relaxed. There were presentations about Gentoo@ IsoHunt, 3D and Linux graphics and Οpen/GnuPG .After the lunch break a Οpen/GnuPG key signing party began outside of the miniconf’s room.After the key signing party we continued with a workshop regarding Puppet also a presentation about how to use testing on Gentoo to improve QA and finally the last presentation ended with Markos and Tomáš talking about how to get involved into development of Gentoo. In the end Theo and Michal closed the session of the miniconf.

 

I really liked Prague especially the beers and the Czech cuisine.

Gentoo Miniconf was a great exp erience for me. I could write lot of pages about the miniconf because I was in the room the whole days and I saw all the presentations.

I had also the opportunity to get in touch and talk with lots of Gentoo developers and contributors from other FOSS projects. Thanks to Theo and Michal for organizing this awesome event.

More about the presentations and the videos of the miniconf  can be found  here.
Looking forward to the next Gentoo miniconf(why not a conference).

A couple of days ago, Tomas and I, gave a presentation at the Gentoo Miniconf. The subject of the presentation was to give an overview of the current recruitment process, how are we performing compared to the previous years and what other ways there are for users to help us improve our beloved distribution. In this blog post I am gonna get into some details that I did not have the time to address during the presentation regarding our recruitment process.

 

Recruitment Statistics from 2008 to 2012

Looking at the previous graph, two things are obvious. First of all, every year the number of people who wanted to become developers is constantly decreased. Second, we have a significant number of people who did not manage to become developers. Let me express my personal thoughts on these two things.

For the first one, my opinion is that these numbers are directly related to the Gentoo’s reputation and its “infiltration” to power users. It is not a secret that Gentoo is not as popular as it used to be. Some people think this is because of the quality of our packages, or because of the frequency we cause headaches to our users. Other people think that the “I want to compile every bit of my linux box” trend belongs to the past and people want to spend less time maintaining/updating their boxes and more time doing some actual work nowadays. Either way, for the past few years we are loosing people, or to state it better, we are not “hiring” as many as we used to. Ignoring those who did not manage to become developers, we must admit that the absolute numbers are not in our favor. One may say that, 16 developers for 2011-2012 is not bad at all, but we aim for the best right? What bothers me the most is not the number of the people we recruit, but that this number is constantly falling for the last 5 years…

As for the second observation, we see that, every year, around 4-5 people give up and decide to not become developers after all. Why is that? The answer is obvious. Our long, painful, exhausting recruitment process drives people away. From my experience, it takes about 2 months from the time your mentor opens your bug, until a recruiter picks you up. This obviously kills someone’s motivation, makes him lose interest, get busy with other stuff and he eventually disappears. We tried to improve this process by creating a webapp two years ago, but it did not work out well. So we are now back to square one. We really can’t afford loosing developers because of our recruitment process. It is embarrassing to say at least.

Again, is there anything that can be done? Definitely yes. I’d say, we need an improved or a brand new web application that will focus on two things:

1) make the review process between mentor <-> recruit easier

2) make the final review process between recruit <-> recruiter an enjoyable learning process

Ideas are always welcomed. Volunteers and practical solutions even more ;) In the meantime, I am considering using Google+ hangouts for the face-to-face interview sessions with the upcoming recruits. This should bring some fresh air to this process ;)

The entire presentation can be found here

I have a really slow ADSL connection but it’s enough to share some bandwidth. Since I’m a strong supporter of privacy, the least I could do – especially now that I’m leaving the place for the summer - was to setup a TOR Relay server. I would love to see more relay servers all over the place. TOR is considerably faster than a couple of years ago for browsing, IRC and other low-bandwith operations. That’s very encouraging.

Since I run a 3350MX box as a home Gentoo server, I just emerged tor, privoxy and g-cpan in order to be able to access Freenode through a “torified” irssi client.

sudo ACCEPT_KEYWORDS=\"perl ipv6\" emerge tor torsocks privoxy irssi g-cpan

Just add this line your torrc, after you do your relay or single tor server configuration:

mapaddress 10.40.40.40 p4fsi4ockecnea7l.onion

It’s good to configure also tor-tsocks.conf file in the /etc/tor directory. Then we add the following line to /etc/privoxy/config

forward-socks4a / 10.0.0.4:9050 .

Then change the configuration at /etc/torsocks.conf to match your network setup. At this point we must emerge some perl CPAN libraries. These are going to be used by irssi SASL script. In theory this step could be made using directly the CPAN manager like:

cpan> install Crypt::Blowfish Crypt::DH Crypt::OpenSSL::Bignum Math::BigInt Math::BigInt::FastCalc Math::BigInt::GMP

However this approach created a myriad of problems to me. It stalled too many times and was not able to compile successfully the Math::FastCalc library. We need this library for faster calculations, since we’re going to encrypt/decrypt packets. Anyway, under Gentoo the approach that worked flawlessly is the following:

g-cpan -iv Crypt::Blowfish Crypt::DH Crypt::OpenSSL::Bignum Math::BigInt Math::BigInt::FastCalc Math::BigInt::GMP

Now we need to configure irssi client. First grab the Freenode SASL perl script. Install it under ~/.irssi/scripts/autorun like:

mkdir -p ~/.irssi/scripts/autorun && cd ~/.irssi/scripts/autorun && wget http://freenode.net/sasl/cap_sasl.pl

Now we just need to add some configuration to irssi. Start irssi preferably on ‘screen -U’ session and run it like:

torify irssi

Now if you see any complaints about ‘cap_sasl.pl’ script then, you need to check the perl installation, make sure that irssi has been compiled with perl support, that the above mentioned libraries are installed etc. If you see no messages then everything is fine. Now let’s configure Freenode and SASL auth:

/network add Freenode /server add -auto -network Freenode p4fsi4ockecnea7l.onion 6669 /sasl set Freenode <primary-nick> <password> DH-BLOWFISH /sasl save /save

Now you should be all setup . We don’t need SSL connection because TOR hidden services are encrypted tunnels, so it would be redundant to use SSL upon hidden services. 

Enjoy Freenode anonymity!! You might encounter a bit of lag, usually is something like 4-5 seconds. It’s the current cost of cloak-ed host on IRC but pays well

Related posts:

1. Going back to the roots: Gentoo
2. Gentoo στο eBox 3350!
3. Gentoo, ruby19 and fcron

<trolling>
12 Μαρ 2012: στόχος μας ως Ελληνική Κοινότητα Gentoo (gentoo-el) είναι να συνεργαζόμαστε με όλους τους εθελοντές και να συμβάλουμε στην δουλειά που γίνεται από κάθε εθελοντή, θα δούμε το πρόβλημα
της πρόσβασης που αναφέρεις και θα σου απαντήσω άμεσα.

Εξακολουθώ να μην έχω πρόσβαση στο gentoo-el.org μέσω SSH. Ο Θοδωρής Χατζημίχος (gentoo-el) κωλυσιεργεί στην ενεργοποίηση πρόσβασης στο gentoo-el.org.

Αλήτη!
</trolling>

Πριν καιρό έγραψα ένα πολύ απλό προγραμματάκι που με χρήση του προγράμματος ping στέλνει παράλληλα πολλά πακέτα σε κάποιον «στόχο», με σκοπό να προκαλέσει DoS και να ρίξει κάποιον «στόχο». Η δημιουργία του έγινε για καθαρά εκπαιδευτικό σκοπό. Παραθέτω τον κώδικά του: /* Program: Ping Of Death Author: Nikolaos Chatzidakis (aka nikhatzi) Disclaimer: To programma