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.
After setting-up replication, if JIRA starts just fine, but Confluence freezes with something similar to:
You cannot access Confluence at present. Look at the table below to identify the reasons.
Type Description Exception Level Time
cluster Non Clustered Confluence: Database is being updated by another Confluence instance. Please see http://confluence.atlassian.com/x/mwiyCg for more details.
Your server id is: SOME-CODE-GOES-HERE
fatal 2015-04-27 00:25:15
This page will automatically update every 60 seconds.
to your server.cnf, as described here.
I’ve just spent hours trying to figure out filters for either users or groups that would allow Confluence and JIRA to authenticate against OpenLDAP only those users that had “member” attribute for respective groups, all in vain. Both Confluence and JIRA simply ignore group membership unless “memberOf” attribute is used during the search. But simply turning the point around works – do not try to force Confluence or JIRA to use “member” attribute found in groups, but simply add “memberOf” attributes to each user you’d like in respective groups.
Unlike mysqld 5.X, mariadb 10.X offers multi-master multi-database replication. That means it can use a single mariadb-server 10.X instance as a replication slave for all the other mysql-servers we need. Unlike supporting this combination, the very installation and set-up is rather straight-forward: Continue reading
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
This morning another pkg update && pkg upgrade failed on my FreeBSD 11 CURRENT amd64. It was some 80-ish packages, and it wouldn’t go past py33-atspi-2.12.0_1. It took a make deinstall && make reinstall of the /usr/ports/ports-mngmt/pkg to complete the upgrade.
I couldn’t figure out in details what caused this awkward situation.
Fortunately, with the exception of the necessity to keep enchant locked if I want gedit to have language dictionaries available in the spell-checker plugin, this is the first clumsiness of the pkgng tool I’ve run into in several months of usage, even under the CURRENT branch.
There, just a brief note! 🙂
A note on strange gedit behaviour: after the last update of ports – yes, there is always something wrong with ports after an update, no matter what it looks like – my gedit wasn’t able to do spell checking, though I was sure I had hunspell and aspell for at least English and German installed system-wide.
Gedit simply displayed no languages in the appropriate menu.
It would re-compile and re-install even from ports, just fine, but no re-compilation of plugins, python bindings or dictionaries helped until I re-installed enchant from ports! There, it might help someone figure out where have all the languages gone:
pkg info gedit\* \*enchant \*aspell
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!