Back to GitHub

After testing Gitlab for some time (both during the free time and working time) I decided that, at least from my usual places, Gitlab is really unusable, so I decided to return to GitHub.

The problem with the private repositories was solved buying a personal plan, which include unlimited private repositories (well, I just need a couples of them, for now).

I will continue to use GitLab for the projects that are hosted there (for now only BugsEverywhere) and my personal repo is still online, but basically all my repos are now on GitHub

New server (again)

So, after some more time and thinking, I changed my mind another time and this site is now hosted back where it was at the beginning, Linode.

Some new activity

Following an effort to minimize the systems I currently maintain (git, mail, www and so on) I am beginning to migrate some services from my own host to some hosted solution.

The first service to face a restructuration is git, with all my private repositories hosted on git.grys.it moved to GitLab, which offer free private repositories.
These private repositories are only the first ones moved, other will follow.

git.grys.it will not die anyway, some really personal repositories will stay on it, at least for some more time.

How to lose 5 year of life: 2° try...

The first try was when I applied a wrong configuration to grub and thereafter the laptop did not boot anymore (ok, it was some years ago...)
This time, after what seemed a normal update of my laptop, which is now running Archlinux, and a concurrent installation of cutegram, I found that I was unable do anything on the machine and I was basically locked out from my machine. Login from console give "login error" even before asking for the password and even with root. SSH did not work and also sudo or su did not work.

After a bit od digging, I was able to reboot to a shell rescue using systemd, I just needed to add the option systemd.unit=rescue.target to the kernel command line.

Once logged in, I begun to look for the problem. The first suspect was cutegram, but it turn out innocent.

After a bit of analisys of the log, I found this error:
Jun 17 23:35:05 galactica login[30384]: PAM adding faulty module: /usr/lib/security/pam_unix.so Jun 17 23:35:01 galactica login[30379]: PAM adding faulty module: /usr/lib/security/pam_access.so
which was followed by
PAM unable to dlopen(/usr/lib/security/pam_unix.so): /usr/lib/libtirpc.so.1: undefined symbol: __rpc_get_default_domain

The basic problem is that I was sure that I had not updated anything related to PAM or friends. The second error, anyway, directed me to the kernelof the problem: for some reason, the libtirpc library was the wrong version (also if I still don't know why).

The first try to solve the problem was to try to run pacman -S libtirpc, which oddly enough update the library: after that the system restarted to work properly.

I still don't know what happened and I am writing this to maybe help someone else. My impression was that it was an unfortunate update timing (since I use a mirror) which for some combination of factor completed my update but at the same time not all the packages in the mirror was at the correct version.

STL Export on Bulbcalculator

BulbCalculator (in HEAD) has now the export to STL file at least as Ascii. This follow a request from a user to be able to print a model with a 3D printer.
Using this request as starting point I added some features that are likely to be used to mill the model, so the STL can also be exported as half model.

There is, for now, a limitation in this since only one half of the model is saved to the STL file.
If you have a model perfectly symmetrical you just have to mill two times the object and you have a complete bulb. Conversely, if you have an asymmetric model (I presume on the vertical plane) this leads to a small amount of work on the CAD/CAM side since you have to generate a mirrored object.

This limitation will be eliminated in a next version, but for now you should keep it in mind if you plan to print (or mill) a bulb designed with BulbCalculator.

Two new features for BulbCalculator

Following a request from a BulbCalculator user, I started the work on implementing the export of the bulb into a STL model file, to be able to print a model with a 3D printer (or to be able to mill the bulb with a milling machine :-) ).

I also started to implemente the possibility to add a hole for the keel, which is somewhat tricky since for any material you remove, you should update the bulb dimension to take care of the difference.

When I started to work on these two features, I realized thatI needed to do some preliminary works that have, as a result, optimizede the code, especially the code that draw the 3D view of the model.

In the end I now have a more real wireframe view, while I added two other view modes: triangles and a real surface. The triangles view was a preliminary work to be able to create the STL file, the other one is just for fun ;-)

Bulbcalculator ported to QT5

After some work, Bulbcalculator is finally ported to QT5, with the future 2.2.0 version. While I am working on this, I also decided to implement some other features, firs of all a recent project list and the possibility to setup the page size, like some very well known CAD programs.

I have not a date to release the 2.2.0 version, since I have not so much time to work on it, but the work is slowly going on.

Working on stl-tools

Stl-tools get some work in the last couple of days which will be the basis for future development.

The main point I nailed out is to have a structure that can support commands that needs different number of parameters.

The old implementation needs to specify the axis for all the operations, but while adding the new operation stubs, I realize that not all of the operations I'd like to implement need the axis specification and, more important, not all of them refer to an axis.

With this in mind I removed the -x option and update the mirror operation to reflect this. The new method is based on a structure (technically a python dict) which hase a "name" , which is the operation itself, and a nested structure (another python dict) which contain all the couples option-value for the operation. This give the required liberty to implement every operation without the risk to touch every part of the code every time I will need to have another option for a new operation.

While working on this, I also corrected the mirror operation definition so now the it is defined to refer to a plane instead of an axis, which is way too more logical.

The last thing done is to move all the help related function to specific class. With this I hope to have a clearer code

stl-tools operation: mirror

This want to be the first of a series of posts that will explain the operation that can be performed by stl-tools

The first, and the one which inspired me to write the software, is mirror

This was the first since I originally write stl-mirror (which later became stl-tools) to mirror a STL file generated from FREE!Ship without the necessity to use a full 3D CAD/CAM program.

Sintax:
stl-tools -i source_file.stl --axis=x|y|z [-o dest_file.stl] mirror

This operation mirror (what a surprise ;-) )the object given in the source_file along one of it's axis (X, Y or Z), writing it to a new file, so also if something is wrong, the original is not lost.

If the -o parameter is omitted, the output file will be named output[sourcefile].stl

On upgrading server software

Short story: when upgrading a production system, always check the release notes of the new version.

Long story.

After the first upgrade of the server following the release of the new Debian stable, I was no more able to send e-mail from my home pc, but I am still able to send from the server itself, which is running Debian testing, so in the following days of the Debian release, testing got a lot of upgrade as usual.

This upgrade also boost postfix to the 2.1.0 release.

Sending mail from my home pc, then result in the error:

May 11 09:28:22 localhost postfix/smtpd[17094]: connect from unknown[79.21.142.151]
May 11 09:28:24 localhost postfix/smtpd[17094]: NOQUEUE: reject: RCPT from unknown[79.21.142.151]: 554 5.7.1 
<gianlum@xxxxxxx>: Relay access denied; from=<gian@grys.it> to=<gianlum@xxxxxxxx> proto=ESMTP helo=<galactica>
May 11 09:28:24 localhost postfix/smtpd[17094]: lost connection after RCPT from unknown[79.21.142.151]
May 11 09:28:24 localhost postfix/smtpd[17094]: disconnect from unknown[79.21.142.151]

It turn out that from this release on, to be able to have a relay (from home I send mail using my server and not the provider's one), you should put the client restriction in the directive

smtpd_relay_restrictions

instead of the old

smtpd_recipient_restrictions

as always in the main.cf file

I discovered this the hard way, since I was in a hurry to send a mail, and before I can find this change, I tried a gazillion other solutions and also checked for every blacklists in the case the server and/or my provider nerwork were blocked.
So, lessons learned:

  1. Always read the release notes (or at least, check them for the important software)
  2. Do not try massive upgrade past 10.00 pm or you will end to lose sleep and do not solve anything anyway, at least until the next morning
  3. If you need to send a very urgent email, send it before trying a massive upgrade :-D