docker-compose binary update

Hackebein commented 4 years ago

Please try to answer all questions. If you cannot, don't just delete it. If you completely ignore or remove the whole template, your issue is either closed or ignored, too. :( This is (not only) because we are evil. Many awesome mailcow supporters don't bother to reply to an issue, when crucial information is missing. Especially when it could have been answered by using this issue template. We need as much information as possible. Please post all logs, do not copy that one line you think may be interesting. Copy the whole bunch and remove sensible information. :) Thank you!

Prior to placing the issue, please check following: (fill out each checkbox with a X once done)

[x] I understand that not following below instructions might result in immediate closing and deletion of my issue.
[x] I have understood that answers are voluntary and community-driven, and not commercial support.
[x] I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description of the bug: What kind of issue have you exactly come across?

https://github.com/mailcow/mailcow-dockerized/blob/master/update.sh#L399 https://www.servercow.de/docker-compose/latest.php returns 1.24.1 instead of 1.25.0. 1.25.0 is out for 13 days now.

https://github.com/mailcow/mailcow-dockerized/blob/master/update.sh#L403 This is not working for alpine linux. alpine linux needs "run.sh" instead of "docker-compose-$(uname -s)-$(uname -m)"

I would recommend the use of file:

# file docker-compose-Darwin-x86_64 docker-compose-Linux-x86_64 run.sh
docker-compose-Darwin-x86_64: Mach-O 64-bit x86_64 executable, flags:<NOUNDEFS|DYLDLINK|TWOLEVEL|PIE>
docker-compose-Linux-x86_64:  ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=28ba79c778f7402713aec6af319ee0fbaf3a8014, stripped
run.sh:                       POSIX shell script, ASCII text executable
docker-compose-pip:           Python script, ASCII text executable

https://github.com/mailcow/mailcow-dockerized/blob/master/update.sh#L395 Maybe we can replace this with the use of file. Just because the pip project docker-compose is (not) installed does not mean that we also use this binary in our update process.

alternative we could use docker-compose inside a container. Then we never need to update a system resource/binary and can use the newest version of docker-compose

Reproduction of said bug: How exactly do you reproduce the bug?

I go to /opt/mailcow-dockerized
./update.sh
press y
Check the logs (see General logs)

System information

Further information (where applicable):

Question	Answer
My operating system	Alpine Linux 3.10.3
Is Apparmor, SELinux or similar active?	no
Virtualization technlogy (KVM, VMware, Xen, etc)	It's a guest of VMware ESXi
Server/VM specifications (Memory, CPU Cores)	2 Core, 4GB ram
Docker Version (`docker version`)	18.09.8-ce
Docker-Compose Version (`docker-compose version`)	1.25.0
Reverse proxy (custom solution)	no

General logs:

# ./update.sh
Checking internet connection... OK
Checking for newer update script...
Updated 0 paths from eabafce3
Are you sure you want to update mailcow: dockerized? All containers will be stopped. [y/N] y
Saving diff to update_diffs/diff_before_update_2019-12-02-01-59-42...
Prefetching images...
1.10: Pulling from mailcow/unbound
Digest: sha256:d7f58b08dabfcfbe8ade7882fe396286a26d042ece671d83ebd6207c136d711f
Status: Image is up to date for mailcow/unbound:1.10
10.3: Pulling from library/mariadb
Digest: sha256:5c2ab07f69d5b353643768adbc4b0a095db44885e49cdc22408511db43ecf1bd
Status: Image is up to date for mariadb:10.3
5-alpine: Pulling from library/redis
Digest: sha256:ee13953704783b284c080b5b0abe4620730728054f5c19e9488d7a97ecd312c5
Status: Image is up to date for redis:5-alpine
1.33: Pulling from mailcow/clamd
Digest: sha256:1eeec1ade8093dad7f3b6f662dbd7ff5dc43df521e3b8f173c72f5700d04a0e3
Status: Image is up to date for mailcow/clamd:1.33
1.56: Pulling from mailcow/rspamd
Digest: sha256:f5af36c7402a7e6c15d150236aca1da17637df43a7b960788c69022af5b6343c
Status: Image is up to date for mailcow/rspamd:1.56
1.54: Pulling from mailcow/phpfpm
Digest: sha256:79c144966648f3559561f40e0995487b7ecc3458a405b34a4e90c0fac26050ef
Status: Image is up to date for mailcow/phpfpm:1.54
1.63: Pulling from mailcow/sogo
Digest: sha256:b8fed8817f2d2e5529d7be9ff27fb63fef14571c5befd2d9fa0793c8787f7a97
Status: Image is up to date for mailcow/sogo:1.63
1.97: Pulling from mailcow/dovecot
Digest: sha256:11c71aac3c84c7989002393d901d9feb944308306d680d6f268bb32475b3a2d5
Status: Image is up to date for mailcow/dovecot:1.97
1.44: Pulling from mailcow/postfix
Digest: sha256:f7d5dcac91e0b4431516366bbc9d056b88031ed50d3174099eae1c378ebd36b5
Status: Image is up to date for mailcow/postfix:1.44
alpine: Pulling from library/memcached
Digest: sha256:3cfb2eee0b618722a62f4cc907fa0ede848efa87d773bb9384044f490926e7ce
Status: Image is up to date for memcached:alpine
mainline-alpine: Pulling from library/nginx
Digest: sha256:0e61b143db3110f3b8ae29a67f107d5536b71a7c1f10afb14d4228711fc65a13
Status: Image is up to date for nginx:mainline-alpine
1.63: Pulling from mailcow/acme
Digest: sha256:23e41be5abd951b4822b66d5fc8a12718a7de8227dad791b3a76b66671b89cb0
Status: Image is up to date for mailcow/acme:1.63
1.31: Pulling from mailcow/netfilter
Digest: sha256:b4d63b46f0261d2aeb46d68b9688316a0886390faeb9a27fdf134ad0a68f18ab
Status: Image is up to date for mailcow/netfilter:1.31
1.62: Pulling from mailcow/watchdog
Digest: sha256:5e5e1b6add40e42e7ad3f3d8dabec1e3c8215d664dbf9db8a7d8b84722550182
Status: Image is up to date for mailcow/watchdog:1.62
1.36: Pulling from mailcow/dockerapi
Digest: sha256:57ea33a968a3f3aec0abaeb1376dc69f56353118ca7f8cb9c7d44e36ba95952c
Status: Image is up to date for mailcow/dockerapi:1.36
1.7: Pulling from mailcow/solr
Digest: sha256:e2e53e6cbed42c6b56961266e14a10f2bc856f88362153f1f1a794a78000dee8
Status: Image is up to date for mailcow/solr:1.7
1.2: Pulling from mailcow/olefy
Digest: sha256:9ddaedf8f9307be00b5243ff11abd37a2ab5897b983ba9e2b6f0580d2ea9f3a4
Status: Image is up to date for mailcow/olefy:1.2
Using default tag: latest
latest: Pulling from robbertkl/ipv6nat
Digest: sha256:90bec3e5898b0000c3ea6f7d6e1ef2347a9887d372968486c3168caf3965497d
Status: Image is up to date for robbertkl/ipv6nat:latest
Stopping mailcow...
./update.sh: line 359: /usr/local/bin/docker-compose: No such file or directory
Committing current status...
Fetching updated code from remote...
Merging local with remote code (recursive, strategy: "theirs", options: "patience"...
Already up to date.
Fetching new docker-compose version...

./update.sh: line 400: /usr/local/bin/docker-compose: No such file or directory
###################################################################################################################################################################################################################################### 100.0%
Fetching new images, if any...
./update.sh: line 415: /usr/local/bin/docker-compose: No such file or directory
Checking IPv6 settings...
Starting mailcow...
./update.sh: line 447: /usr/local/bin/docker-compose: No such file or directory
Collecting garbage...
Further cleanup...
If you want to cleanup further garbage collected by Docker, please make sure all containers are up and running before cleaning your system by executing "docker system prune"

Hackebein commented 4 years ago

After thinking about it. We should not replace system files. This is not the job of mailcow.

I don't wanna disrespect someone. I understand what the meaning behind it and the good intentions. The more I think about it, the less attractive this update function seems to me. This look very ugly. Even my recommendation with the using of file looks ugly to me now.

We should use docker-compose inside a container or only check the docker-compose version and warn the user that the current used version is outdated.

andryyy commented 4 years ago

It is 1.24.1 because 1.25.0 was broken with mailcow. I'm still not sure it works, but it should. I don't want to risk it, just because someone is unhappy to not be on the latest of the latest compose binaries. I really want to wait for 1.25.>0.

So... it worked absolutely as intended. That's the whole point of me controlling that version. Instead of everyone running into the knife, we were able to stop broken mailcows.

If you don't like it: change the update script on your system. :)

PS: It was the first time ever, we didn't just read the latest version from GitHub and forward it. This was never something static we needed to update manually. If you want to install it from an outdated repository, make sure you read all issues on here why that's a bad idea. It is like people using Rspamd from the Debian repository. It is broken as fuck, but some still consider it a better alternative, because it's in Debians repository. It isn't. :)

nightah commented 4 years ago

@andryyy do you recall what the issue was with 1.25.0? I've been running it for about two weeks with no noticeable issues, happy to do some testing to confirm this if you like.

andryyy commented 4 years ago

Yes. The build flags. I moved them. I want to wait for 1.25.1 anyway.

Keridos commented 4 years ago

As of now the update script still overwrites my docker-compose in alpine linux with a version that is not correctly linked. So it basically breaks my systems docker-compose installation. Should I open up another issue for that?

MAGICCC commented 4 years ago

As said in the IRC I forwarded it and @andryyy thought about adding a skip option to the update script.

andryyy commented 4 years ago

It is implemented now.

https://github.com/mailcow/mailcow-dockerized-docs/blob/master/docs/i_u_m_update.md

mailcow / mailcow-dockerized

docker-compose binary update #3181