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.
An openSUSE 13.2 workstation I use for some time now simply froze on clicking “Yast >> System >> Bootloader >> Kernel_parameters (tab)”.
The only thing I can find on that topic is this post, descriptive, but not particularly useful in tracking the problem. As said there, a reboot fixed the things up.
“Have you tried to turn it off, and on again?” is still a preferred method in IT?
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