Recently, I’ve stumbled upon diaspora, a social network platform that has more than enough potential, but a giant show-stopper as well – the SSL certificates, used (amongst other things) to enable secure communications between diaspora’s nodes, or “pods” in disapora lingo, have to be “official”, signed by an “authoritative issuer”. Since some of us see that detail as a general problem for proper communication, especially in the light of the events and affairs surrounding “the official authorities” for the SSL certificates in recent years, I have decided to try to overcome that detail, and use otherwise good and usable code of diaspora, and fork it into something that would provide similar usability, yet be tolerant for the self-signed certificates. After I have read the copyright documents that comes with diaspora’s code, I conclude that there should be no problems to fork it, as long as the Affero General Public License version 3 is respected.
Initial brainstorming are going to happen it the next few days on #rapsodia channel at ircer.simulakrum.org IRC server, and everyone with a piece of code, a constructive idea, or more, is welcome. See you at rapsodia, hopefully more than just an IRC channel, soon 🙂
Here is a quick and dirty note on what can go wrong with ports for OpenBSD 5.4 > 5.5 update, hope it helps someone: Continue reading
I’ve pulled a git repo in /srv/poligon through Eclipse, so I could avoid messing with the permissions for the home directory while testing the changes on the localhost, too. After setting the directory’s permissions, a localhost’s nginx still wasn’t able to access pages there; SELinux is set to “enforcing” by default in Fedora 20, so you’ll need another permissions’ setting for the directory:
chcon -R -t httpd_sys_rw_content_t /srv/poligon/
After this change, nginx should be able to pass the pages to php-fpm without problems on a SELinux enforcing host.
I had moved some of the testing repositories and the Eclipse from an OpenSuSE 13.1 to a Fedora 20. Since the git had most of the configuration options set locally, I expected everything to work after a simple copy&paste to the new environment, respecting the old paths. However, Eclipse started complaining when trying to push or clone from gerrit.simulakrum.org yet the operations worked fine from the same laptop when using ssh; I tested the https access to gerrit.simulakrum.org from another computer and user, and that worked fine. The messages Eclipse was returning were:
An exception occurred during push on URI
cannot open git-receive-pack
and Google was leading to texts that had almost the same response, something like “if it is not working over https, try git, or ssh…”
I took me a while to remember that I tried to imitate the totalitarian environment and the firewall of the math department at my university through usage of Tor and a proxy for Eclipse, because they were obstructing even the ssh port, following the stupid-and-old “golden” rule that says “if you don’t know what’s it for, cut it down!”, and with the change of the distribution, I have changed the proxy, too. Polipo was listening at 8123, and a brisk change to privoxy’s 8118 in the Eclipse’s initiation scripts brought it all back to “normal”.
The moral of the story should close this text, but everything I previously wrote for this closing was too cynical to be published, so I’ll just skip it for once. I’ll just add to the myriad of advices found on StackOverflow to change the protocol – just for the record – that badly formed https_proxy variable can be the cause of those Eclipse’s errors, too.