I wanted to install dolibarr on my arch linux machine.
The first steps are simple and I tried to stick to the official but little outdated aur package.
git clone https://github.com/dolibarr/dolibarr -b 14.0.1 .
choown -R http:http dolibarr
sudo -u http touch dolibarr/htdocs/conf/conf.php
cat > /etc/httpd/conf/extra/httpd-dolibarr.conf <<DELIM
Alias /dolibarr "/usr/share/webapps/dolibarr/htdocs"
Options FollowSymlinks Indexes
Require all granted
# vim: set ft=apache ts=2 sw=2 et:
echo "#dolibar" >> /etc/httpd/conf/httpd.conf
echo "Include conf/extra/httpd-dolibarr.conf" >> /etc/httpd/conf/httpd.conf
systemctl restart httpd.service
After that, I wanted to open my
http://<hostname>/dolibarr and it worked out quite well. The build in installation routine started and I was able to click to the next page to check the system.
Almost all went well but it took me hours to figure out why the installation routine complained about the
conf.php file. It had the right permissions (
u+rw) but the php built in
is_writable is returning
false for this file.
It wasn't a running selinux, it wasn't a wrong configured php
open_basedir or php
safemode. It really turned out, that apache http refuesed to allow writing to a file outside than the configured home path of
Even a softlink created in
/srv/http linking to
/usr/share/webapps/dolibarr was not working.
What was working is to
mv /usr/share/webapps/dolibarr /srv/http and to adapt the
So, after telling it a longer time, github has disabled it https authentication mechanism.
From now on, you have to use ssh keys and a configuration. Following is a simple how to do it.
First of all, generate your ssh key
#my advice, name the key to your usage
ssh-keygen -t rsa -b 4096
Next up, you have to upload the pub key to github account.
After that, you have to adapt the
This was the easy part. Now to the final step that took me ages. You have to go through all your repositories and check if you use ssh or http as the transport protocol to work with github.
Go to a repository and open up your
Replace any thing that starts with
firstname.lastname@example.org:.... It should only be in the lines starting with
git remote -v should work fine. But yes, you have to do it for all repositories.
If you have to stick to use HTTPS operations (like working from behind a firewall where ssh port 22 is restricted), try to follow this guide to setup an access token per device.
- Open your developer settings new token page
- Give it a name like "work "
- Give it an expiration date
- select the scopes and permissions
- Click on
- Update your credential manager
- e.g. Windows it is the clickpath
control panel -> credential manager -> generic credentials
- or for german windows users
systemsteuerung -> benutzerverwaltung -> eigene anmeldeinformationen verwalten -> windows-anmeldeinformationen -> github.com auswählen
I am using the zfs-snap-manager for such a long time that I never ever had a look on it since years.
I've just created zfs pools and zfs snap manager configurations without thinking or checking it for a while now.
But once upon a time I wanted to check the behaviour and found out that some configured snapshots where not made.
After a while I saw that my assumption was false, so the error was in front of the display .
My configuration for the section
schema was simplified to
7d because all I wanted for a dataset was that I can go back the last seven days.
After finding the log file (
/var/log/zfs-snap-manager.log) and tailing it, I quickly saw the log message
Got invalid schema for dataset .... Just a bit more investigation and I found out that I have to provide a fully defined schema like
After adapting all available configuration files on all hosts, the zfs-snap-manager is working as expected.
I found an existing feature request to "relaxed" the schema interpretion and stumpled over another feature request asking for creating unittests. So I've forked it and will try to learn python by fixing the issue on my own.
- migrate code to python3
- write unittests
- implement relaxed handling of schema with default values
Do you want to join? Contact me if you want to.
As written in the official issue ticket, following the way how to solve your conflict locally.
A quick update to figure out the conflicted files.
cd into your nextcloud synchronized path
#list conflicted files
find . -iname *conflic* -type f
You can than decide which file is the one you want to keep
foo (conflicted copy 2020-09-09 083407).bar.
See also here and here.