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