Hi, I have had problems installing nav 57.1-2 on a Debian 11 from NAV repository with 'apt install nav'. The installation give the following warning, you have the choice to click OK. Database initialization failed │ │ Script output: │ │ Traceback (most recent call last): │ File "/usr/sbin/navsyncdb", line 2, in <module> │ from nav.pgsync import main │ ModuleNotFoundError: No module named 'nav' <Ok>
It is not possible to run "sudo -u postgres navsyncdb" after the installation either, same error message, for the same reason as above.
I found that the symlinks are setup somehow wrong for nav binaries installed. I'm not a good python programmer but probably the virtual env is not setup or configured as it should.
/opt/venvs/nav/bin# ls -l python* lrwxrwxrwx 1 root root 16 Sep 18 14:09 python -> /usr/bin/python3 lrwxrwxrwx 1 root root 6 Sep 18 14:09 python3 -> python lrwxrwxrwx 1 root root 6 Sep 18 14:09 python3.9 -> python
because in my case: /usr/bin/python3 -> python3.11
And ### /opt/venvs/nav/pyvenv.cfg home = /usr implementation = CPython version_info = 3.9.2.final.0 virtualenv = 20.4.0+ds include-system-site-packages = false base-prefix = /usr base-exec-prefix = /usr base-executable = /usr/bin/python3
So I chnged base-executable to /usr/bin/python3.9 And the links to
/opt/venvs/nav/bin# rm python /opt/venvs/nav/bin# ln -s /usr/bin/python3.9 python
So everything points to Python 3.9.2.
Now with every attempt for installation of any package I get:
Configuring nav │ │ Attempt to modify config file /etc/nav/db.conf failed │ │ │ Script output: │ │ <Ok>
It seems that dpkg wants to run post installations and something goes wrong.
And this output:
Configuring nav │ │ Database initialization failed │ │ Script output: │ │ connection to server at "localhost" (::1), port 5432 failed: FATAL: │ password authentication failed for user "nav" │ connection to server at "localhost" (::1), port 5432 failed: FATAL: │ password authentication failed for user "nav" │ │ Creating database nav owned by nav │ │ <Ok>
E: Sub-process /usr/bin/dpkg returned an error code (1) I have tried to drop the database, creating new database, changing the password, set the password other ways, uninstall nav and reinstall but without any results. I am out of ideas and any help is appreciated. Fixing the instalation scripts or Python venvs is it possible to do?
Kind Regards, Kejvan
On Sat, 7 Oct 2023 22:14:03 +0000 (4 days, 8 hours, 32 minutes ago) Kejvan Redjamand kejvan@chalmers.se wrote:
Hi,
I have had problems installing nav 57.1-2 on a Debian 11 from NAV repository with 'apt install nav'.
Hi there,
I suppose you mean 5.7.1-2bullseye.
I found that the symlinks are setup somehow wrong for nav binaries installed. I'm not a good python programmer but probably the virtual env is not setup or configured as it should.
/opt/venvs/nav/bin# ls -l python* lrwxrwxrwx 1 root root 16 Sep 18 14:09 python -> /usr/bin/python3 lrwxrwxrwx 1 root root 6 Sep 18 14:09 python3 -> python lrwxrwxrwx 1 root root 6 Sep 18 14:09 python3.9 -> python
This is perfectly normal for a virtualenv built on a standard Debian Bullseye distribution, which comes with Python 3.9.
because in my case: /usr/bin/python3 -> python3.11
Now that's a pickle. Debian 11 doesn't provide Python 3.11. Did you install Python 3.11 from some backports repository?
I have tried to drop the database, creating new database, changing the password, set the password other ways, uninstall nav and reinstall but without any results.
I am out of ideas and any help is appreciated.
The Debian package will generate a random database password and modify /etc/nav/db.conf at installation time. If re-running the package config at a later date, it will assume the database has already been initialized if the password is already there in db.conf. In your case, that is probably not true, since the database scripts crashed, so now the package init is likely trying to access a non-existant database.
I would verify that there is a password set in the `userpw_nav` option of /etc/nav/db.conf (if set, just leave it. If not, make up your own), and then just attempt to reset the whole database from scratch using navsyncdb as the postgres user, thus:
sudo -u postgres navsyncdb --drop-database -c
Hi Thank you for your effort. did not know that it is a requirement to install nav on a vanila Debian. I don’t know either what happens with the links if one updates the system or Python to a higher version.
Thank you once again. Kejvan
Med vänliga hälsningar Kejvan Redjamand ________________________________ From: Morten Brekkevold morten.brekkevold@sikt.no Sent: Thursday, October 12, 2023 8:46:32 AM To: Kejvan Redjamand kejvan@chalmers.se Cc: nav-users@lister.sikt.no nav-users@lister.sikt.no Subject: Re: [Nav-users] nav installation
On Sat, 7 Oct 2023 22:14:03 +0000 (4 days, 8 hours, 32 minutes ago) Kejvan Redjamand kejvan@chalmers.se wrote:
Hi,
I have had problems installing nav 57.1-2 on a Debian 11 from NAV repository with 'apt install nav'.
Hi there,
I suppose you mean 5.7.1-2bullseye.
I found that the symlinks are setup somehow wrong for nav binaries installed. I'm not a good python programmer but probably the virtual env is not setup or configured as it should.
/opt/venvs/nav/bin# ls -l python* lrwxrwxrwx 1 root root 16 Sep 18 14:09 python -> /usr/bin/python3 lrwxrwxrwx 1 root root 6 Sep 18 14:09 python3 -> python lrwxrwxrwx 1 root root 6 Sep 18 14:09 python3.9 -> python
This is perfectly normal for a virtualenv built on a standard Debian Bullseye distribution, which comes with Python 3.9.
because in my case: /usr/bin/python3 -> python3.11
Now that's a pickle. Debian 11 doesn't provide Python 3.11. Did you install Python 3.11 from some backports repository?
I have tried to drop the database, creating new database, changing the password, set the password other ways, uninstall nav and reinstall but without any results.
I am out of ideas and any help is appreciated.
The Debian package will generate a random database password and modify /etc/nav/db.conf at installation time. If re-running the package config at a later date, it will assume the database has already been initialized if the password is already there in db.conf. In your case, that is probably not true, since the database scripts crashed, so now the package init is likely trying to access a non-existant database.
I would verify that there is a password set in the `userpw_nav` option of /etc/nav/db.conf (if set, just leave it. If not, make up your own), and then just attempt to reset the whole database from scratch using navsyncdb as the postgres user, thus:
sudo -u postgres navsyncdb --drop-database -c
-- Sincerely, Morten Brekkevold
Sikt – Norwegian Agency for Shared Services in Education and Research
-
Kejvan Redjamand -
Morten Brekkevold