If your ssmtp persistently returns a “SSL not working: certificate verify failed (18)” in logs, and you do have “TLS_CA_File=/etc/pki/tls/certs/ca-bundle.crt” in your conf, and you do use a self-signed certificate, try adding the certificate in “/usr/share/pki/ca-trust-source/anchors/” (Fedora 22 directory, may vary for other distros) and then re-try the mailer agian.
Running a private docker-registry behind a few proxies took me while to configure, because I had several things that I couldn’t move. In particularly, it is an nginx in front of everything, and the docker-registry that I wanted as a “real” service, because I am still learning the docker ways, and I don’t want it as a container, yet.
I installed the docker-registry in a KVM VM, on a CentOS 7 – a standard business requirement one might say.
Running Docker containers behind a firewalld can be a routing nightmare. I had to use CentOS 7 docker images on a customised CentOS 7 host, and the situation turned into an incompatibility fest pretty soon after I figured out the followng:
- CentOS host came with no firewall, and systemctl listed dbus-org.fedoraproject.FirewallD1.service,
- Dockerised CentOS containers have no systemd,
- Docker’s internal routing isn’t exactly the shiniest piece of documentation on Docker,
- IPTables-services and firewalld shouldn’t work simultaneously, and usage of IPTables-services is strongly discouraged on new hats, in favour of new the interface – firewalld,
- Docker’s daemon uses own interface to write to Netfilter, that can be clearly visible by an “iptables -L” inspection,
- Docker (apparently) creates random RFC1918 addresses for new containers,
- Docker assigns two IPs for each container regardless of the third IP you might call for on the command line during “docker run…”.
After a trillion of attempts, here is the most sane and simple solution I have come by for now: Continue reading
I installed an openSuSE 13.2 x64. I opted out btrfs and went with ext4. I logged in and found zombies on a freshly installed and updated OS:
lizzy:~ # ps ajx | grep -w Z | grep -v grep ; uname -a
9955 10011 1149 1149 ? -1 Z 0 0:05 [btrfs-defrag-pl]
9955 10012 1149 1149 ? -1 Z 0 0:05 [snapper.py]
Linux lizzy 3.16.7-7-desktop #1 SMP PREEMPT Wed Dec 17 18:00:44 UTC 2014 (762f27a) x86_64 x86_64 x86_64 GNU/Linux
Zombies are coming from the btrfs-something-backend, but why? Those are a perl and a python scripts, ran from who-knows-where-and-why, and I will find them, and tame them, but this is not looking good – first I got some Adobe’s garbage (IC profiles and that idiotic flash player) pre-installed, and it took me a few minutes to figure out where to declare those as persona non-grata in yast, making sure they won’t try to update or install again on every single operation with packages! Now the zombies…
“This does not bond well, commander…”; yet XCOM is working flawlessly, out of the box, with the FLOSS radeon driver, and the dreadful NetworkManager is not calling home – openSUSE introduces wicked here, a home-brew connections manager that actually co-operates with the user well (unlike the NM, that hijacks everything it can, systemd-style). I’ll keep this lizard in my digital garden a bit more…
Unfortunately, Debian is the only distro I have managed to install in (still somewhat an experimental) bhyve hypervisor on FreeBSD. With Slackware, Gentoo, OpenSuSE, CentOS and Fedora I have previously failed, but Debian seems to be playing just fine:
Debian it is then, for my GNU/Linux needs!
While the infamous systemd brought into the Linux community through the gates of Fedora is in its peak of sowing, yet another sensitive detail regarding Fedora was recently brought to my attention: bitlord from LUGoNS noticed a supposed behaviour for 21 that he soon reported to the tracker:
To me, the most interesting part of the thread was the initial reaction of many of the community members, derogating the issue of a program (NetworkManager) pinging the world in a pretty conspirational manner.
Binding GNOME3 so tightly to fully linux-centric systemd (and vice-versa, making reserved space for GNOME3 manoeuvring inside systemd space) was an obvious demonstration of the force, but it was an open one, clearly visible from all points of interest. “A pinging service” within the NetworkManager is far less obvious, so if it becomes a model of incorporation of novelties for Fedora, it will become a very bitter vector of equally bitter change.
As Peter Mlakar once read for Laibach, I too do not like moralities and surely even less like to preach about moralities, but the ideas that becomes obsessed with moral values (and the distros that take the leadership away from technical persons just to give it to the lawyers) is now forcing me to do so.
Or I can quietly and completely switch to something I still consider sane, like OpenBSD…
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’ve noticed that I cannot connect to an SSL port of an IRC server running on an .onion address using torsocks on a linux. Using the OpenBSD’s irssi-0.8.15p3-socks works fine, though, just as using Xchat with usewithtor option. For instance, using
vanja@ip:~> usewithtor irssi
/connect -ssl tn3zho2yrhkdpmo7.onion 6697
simply hangs the connection. There are a few traces in the terminal about the problem:
libtorsocks(17204): The symbol res_querydomain() was not found in any shared library. The error reported was: not found!
Similar traces get spilled in the very irssi’s window if proxychains are used:
-!- Irssi: Unable to connect server tn3zho2yrhkdpmo7.onion port 6697
[(status)] |DNS-request| tn3zho2yrhkdpmo7.onion
|DNS-response|: tn3zho2yrhkdpmo7.onion is not exist
The solution that works well for irssi on OpenSuSE 13.1, Debian 7, and Scientific Linux 6.5 is to use socat, just like it is explained at Tor’s pages for irssi:
$ socat TCP4-LISTEN:4242,fork SOCKS4A:localhost:tn3zho2yrhkdpmo7.onion:6697,socksport=9050
and then from within irssi:
/connect -ssl localhost 4242
That should allow irssi to connect to an SSL port of an IRC server running on an .onion address.
Your BackupPC is on a GNU/Linux? You’ve triple-checked the set-up and dependencies, and all but an OpenBSD machine works, while the OpenBSD fails, with
backup failed (fileListReceive failed)
in logs? That is just Scientific Linux BackupPC failing to find OpenBSD’s rsync under /usr/bin. Make a symlink in OpenBSD, from /usr/local/bin/rsync to /usr/bin/rsync, and everything should start as expected…