A big part of my work has to do with code. I’ve worked as system administrator – installing, patching, and configuring someone else’s code. I’ve worked as independent programmer, writing code on my own. I also programmed as part of the team. And on top of that, I worked as Team Leader and Project Manager, where I had to interact a lot with programmers. Programming world on its own is as huge as the universe. There is always something to learn. When I find something worthy or something that I understand enough to write about, I share it in this category.
As mentioned before, over the last few month I’ve been involved in quite a few integration projects, using mostly SugarCRM and Request Tracker. One of the interesting challenges was the Single Sign-On (SSO) between the two.
Continue reading Single Sign-On Between SugarCRM and Request Tracker
SugarCRM comes with a variety of modules that store values in the database. Some of those values are encrypted. For example, mailbox passwords for inbound and outbound email configurations.
When you create this configurations through the web interface or the API, you don’t need to worry about encryption, as SugarCRM handles that all by itself. But sometimes, you need to access those values from third-party code. The easiest way would be of course to use the same API functionality, but this is not always possible (different machines, different technology stack, etc).
It is still possible decrypt the values in the database, if you know where to look.
First of all, here is a little side note for InboundEmail and OutboundEmail modules. InboundEmail is a full-featured module, which you can find in modules/InboundEmail folder. OutboundEmail is however not – it lives in include/OutboundEmail . This might seem surprising, but the reason for this (probably, as I don’t know for sure) is that outbound email configuration is much simpler. Inbound emails are linked with folders, which are then used to subscribe users, etc. Outbound emails are just SMTP configurations to use, directly linked to users.
Anyways. Let’s get back on track.
Most of the encryption and decryption magic happens in include/utils/encryption_utils.php. If you look through the code, you’ll notice that it deals with mostly two things:
Encryption keys are stored in custom/blowfish/ folder. The files that you’ll find there have weird names and a .php extension. The name of the file comes from the module, for which the key will be used. ROT13 algorithm is used to convert the name of the module into the file name. (Note, that for outbound email, the name of the module is OutBoundEmail, not OutboundEmail).
If the encryption key file does not exist, a new one will be generated. The file will contain a PHP snippet like this:
<?php // created: 2016-04-18 10:00:00 $key = array ( 0 => 'a0a0a0a0-b1b1-c3c3-d4d4-e5e5e5e5e5e5', );
If you accidentally remove the file, then you won’t be able to decrypt any of the values, encrypted with this key, so make sure you backup this up. Especially considering that this folder might be in your .gitignore, as a sub-folder of custom/ which stored lots of auto-generated stuff.
Note that the file actually defines a $key variable, which, if you will include it in your code, can overwrite your $key variable. So, be warned.
Now, the encryption and decryption is handled with the Crypt_Blowfish library from Pear. You can find it in include/Pear/Crypt_Blowfish folder.
A little note for the above as well. The Blowfish.php file which contains the Crypt_Blowfish class, requires the Blowfish/DefaultKey.php file (from the setKey() method). That requirement uses relative path, but not based on the current file. Yeah, I know. So, if you just copy over the library somewhere else, you might need to adjust either path variables, or the setKey() method.
Armed with this knowledge, you can now work with encrypted values stored by the SugarCRM in the database. Good luck!
There’s nothing like working on a problem for a few days and getting to the reassuring code snippet like this:
sub PSGIApp {
my $self = shift;
# XXX: this is fucked
require HTML::Mason::CGIHandler;
require HTML::Mason::PSGIHandler::Streamy;
my $h = RT::Interface::Web::Handler::NewHandler('HTML::Mason::PSGIHandler::Streamy');
$self->InitSessionDir;
my $mason = sub {
my $env = shift;
# mod_fastcgi starts with an empty %ENV, but provides it on each
# request. Pick it up and cache it during the first request.
$ENV{PATH} //= $env->{PATH};
# HTML::Mason::Utils::cgi_request_args uses $ENV{QUERY_STRING} to
# determine if to call url_param or not
# (see comments in HTML::Mason::Utils::cgi_request_args)
$ENV{QUERY_STRING} = $env->{QUERY_STRING};
The first comment is misleading. It throws you off. Almost make you close the file and go somewhere else. But that’s just a little frustration from the last few days. The solution to my problem is here too… And that’s when the warm, cozy feeling I have for the Open Source Software kicks in.
P.S.: both the problem and the solution will be posted separately.
After all the reading about Ansible that I’ve done yesterday, I woke up today with a strong will to try it out. Running a few “hello world” examples wasn’t illustrative enough, so I decided to migrate my dotfiles repository from Puppet to Ansible. This would provide just enough complexity to try things out, without any danger of breaking things horribly.
I’m proud to say that it took me only about two-three hours of trying things out to complete this task. In the process, the following things were tried:
One of the things that I haven’t tried yet is using non-core modules (Ansible Galaxy, etc). I will, eventually. But for now I have to say that Ansible provides enough functionality out of the box to run the most common tasks.
When I was done, the resulting change set had (according to diffstat):
The majority of these changes were, of course, the removal of Puppet modules from the repository, not the actual configurations.
My initial impressions are:
Overall, I’m pretty happy with how it goes. Next up – trying it out for provisioning some of my servers. And then, if all goes well, using it for project deployment as well.
It’s Thursday evening of a particularly difficult week at work. Tomorrow is a public holiday, effectively making this – a Friday. My brain is blank and exhausted, so I can’t do anything productive. And I’m too tired to go out. But I can still learn a thing or two.
First things first – cancel the external noise. I want something loud, but not too intensive, and with no words in it. So this 2 hour blues instrumental collection comes in handy. Start the playback, put the headphones on, and push the volume up.
Now. Here’s something I wanted to look into for quite some time – Ansible configuration manager.
Continue reading Checking out Ansible. Sorry Puppet