Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Use Debian Bookworm #48

Open
mayeulk opened this issue Jul 25, 2023 · 5 comments
Open

Use Debian Bookworm #48

mayeulk opened this issue Jul 25, 2023 · 5 comments

Comments

@mayeulk
Copy link
Contributor

mayeulk commented Jul 25, 2023

Originally posted by @fititnt in #45 (comment)
Hi @mayeulk , this issue is now fixed. Maybe I will have newer ones, feel free to open other issues.
I didn't attempt to use the very last Debian 12 Bookworm (which will have a LTS by 2028, see https://endoflife.date/debian) but now is the Debian 11 (Bullseye), but if you want we could do a quick check.

Relevant point which is different from current Uwazi documentation: this Uwazi-docker is using MongoDB 6.0, not the MongoDB 4.2, which I had problems using recently Debian. In theory the Uwazi app is working, but I haven't tested every feature, so in particular @acme might need to do tests on a backup (not main database) and maybe warn me if it was a bad idea.

If you all have some time next weeks and are interested, I could try to test again on very recent Debian, so we might push the versions up and for several years just keep doing minor incremental upgrades. For now I only done with MongoDB.

But, as expected, the fititnt/uwazi-docker, even with current approach of point to latest production tag of uwazi, is granted "to break" after some years because of the dependencies, however this likely to be better since at least the ones who are users don't stay with version too older.

@mayeulk
Copy link
Contributor Author

mayeulk commented Jul 25, 2023

I tried to replace
FROM node:18-bullseye
by
FROM node:18-bookworm
in the Docker file, then deleted the 3 containers from the Uwazi stack, then:
docker-compose run -e IS_FIRST_RUN=true --rm uwazi --build
docker-compose up --build --force-recreate --no-deps -d uwazi

It seemed to work well, I played with the Uwazi GUI during 20 minutes afterwards.
Still, some warnings:

=> [2/7] RUN DEBIAN_FRONTEND=noninteractive apt-get update && apt-get install -y bzip2 dh-autoreconf git libpng-dev gnupg poppler-utils 17.6s
=> [3/7] RUN curl -fsSL https://pgp.mongodb.com/server-6.0.asc | gpg -o /usr/share/keyrings/mongodb-server-6.0.gpg --dearmor 1.1s
=> [4/7] RUN echo "deb [ signed-by=/usr/share/keyrings/mongodb-server-6.0.gpg] http://repo.mongodb.org/apt/debian bullseye/mongodb-org/6.0 main" | tee /etc/apt/sources.list.d/mongodb-org-6.0.list && apt-get upda 81.0s
=> [5/7] RUN git clone -b "production" --single-branch --depth=1 https://github.com/huridocs/uwazi.git /home/node/uwazi/ && chown node:node -R /home/node/uwazi/ && cd /home/node/uwazi/ && yarn install && ya 344.0s

1/5 Validating package.json
2/5 Resolving packages
Warning Resolution field [email protected] is incompatible with requested version [email protected]
Warning Resolution field [email protected] is incompatible with requested version [email protected]
Warning Resolution field [email protected] is incompatible with requested version [email protected]
(and quite a few more:)
react-redux-form
react-text-selection-handler

=> => # warning " > [email protected]" has incorrect peer dependency "react-dom@^0.14.7 || ^15.0.0 || ^16.0.0".
=> => # warning " > [email protected]" has incorrect peer dependency "react-dom@^17.0.1".
=> => # warning " > @testing-library/[email protected]" has unmet peer dependency "@testing-library/dom@>=7.21.4".
=> => # warning " > [email protected]" has unmet peer dependency "axe-core@^3 || ^4".
=> => # warning " > [email protected]" has incorrect peer dependency "cypress@^4.5.0".

Unfortunately, this was displayed as a sub-process in the console, which prevented copy-paste, and let only a few lines be displayed while exporting the console output afterwards.

@mayeulk
Copy link
Contributor Author

mayeulk commented Jul 25, 2023

@fititnt , you mentioned " In theory the Uwazi app is working, but I haven't tested every feature, so in particular @acme might need to do tests on a backup (not main database) and maybe warn me if it was a bad idea."

Is there a test database already populated with documents, a full data model with many relationships among entities, a rich collection, etc?
This could help testing a lot.
Thank you.

@mayeulk
Copy link
Contributor Author

mayeulk commented Jul 25, 2023

Also, possibly a useful discussion:
nodejs/docker-node#1918

The update of the base OS image used for node:18 from Debian 11 to 12 has caused issues for various people:
nodejs/node#43064 (comment) (last comments)
nodejs/docker-node#1916
nodejs/build#3382

@fititnt
Copy link
Owner

fititnt commented Jul 30, 2023

Is there a test database already populated with documents, a full data model with many relationships among entities, a rich collection, etc?
This could help testing a lot.
Thank you.

Yes, now we have, added on #51.

It seemed to work well, I played with the Uwazi GUI during 20 minutes afterwards.
Still, some warnings:

These warnings are from Uwazi production tag (most of the about how is build the nodejs dependencies). But they're mostly harmless.

Whith the -e UWAZI_GIT_RELEASE_REF=production (changing the parameter for another tag) allow get different version. But this still not using the released tgz files suggested on #49 .

Also, possibly a useful discussion: (...)

Yes, the Debian Bookworm is quite new, so for who is migrating from older apps, they would have more issues than as soon as it become stable, you or me change the fist line from the Dockerfile to use the lastest stable debian.

But anyway, one reason to not upgrade for Bookworm was test a bit if other parts are obviously broken (like the #50, that problem with redis would affect every distro) but I think that now, if theres nothing else broken, and the app is running, then it could be attempted to just upgrade for Bookworm and we stick with it for next several years.

@fititnt fititnt pinned this issue Jul 30, 2023
@fititnt
Copy link
Owner

fititnt commented Dec 14, 2023

Ok, a new report found by @hakkiunlu found a error on we not using the exact mongo 4.2

#52 (comment)

Well, the error @hakkiunlu got is true. I even downgraded to not use the lastest version around the time of this new change with the following (the UWAZI_GIT_RELEASE_REF=1.126. overwirtes which version is installed from Uwazi):

docker compose run -e IS_FIRST_DEMO_RUN=true -e UWAZI_GIT_RELEASE_REF=1.126.0 --rm uwazi

and with Mongo 6.0 (which we're using because 4.2 is more complex to deploy with newer Debian) it will fail.

In theory, needs rewrite the setup script and preferable in a easy-to-run way, without manual steps. And If the problem is merely this, all other things still working, we might better try to still on latest MongoDB (but we already know that this needs more testing to go in production, otherwise, is better to stay on the very strict versions used by the Uwazi documentation.


Issues related related:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants