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.
#as root
cd /usr/share/webapps
mkdir dolibarr
cd dolibarr
git clone https://github.com/dolibarr/dolibarr -b 14.0.1 .
cd ..
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"
<Directory "/usr/share/webapps/dolibarr/htdocs">
AllowOverride All
Options FollowSymlinks Indexes
Require all granted
</Directory>
# vim: set ft=apache ts=2 sw=2 et:
DELIM
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 /srv/http.
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 httpd-dolibarr.conf.
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
#e.g.: com_github_<yourusername>
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 ~/.ssh/config file.
Host github.com
Hostname github.com
User git
PreferredAuthentications publickey
IdentityFile ~/.ssh/com_github_<yourusername>
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 .git/config file.
Replace any thing that starts with https://github.com/... with git@github.com:.... It should only be in the lines starting with url =.
After that 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.
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 7d0w0m0y.
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