Hi all,
I tried to omnibus GitLab install on the VM. Failed on: Expected process to exit with [0], but received '255' ---- Begin output of sysctl -e -p /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf ---- STDOUT: STDERR: sysctl: setting key "kernel.shmmax": Read-only file system ---- End output of sysctl -e -p /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf ---- Ran sysctl -e -p /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf returned 255
Due to: command "sysctl -e -p /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf" causing the error: sysctl: setting key "kernel.shmmax": Read-only file system
Read-only of the /sys/ directory is typical the case with LCX containers... But the advice value of the shmax is: cat /opt/gitlab/embedded/etc/90-omnibus-gitlab-kernel.shmmax.conf kernel.shmmax = 17179869184
I can complete the setup if you want, by using a workaround by commenting-out the related section in: /opt/gitlab/embedded/cookbooks/cache/cookbooks/package/resources/gitlab_sysctl.rb. And run: gitlab-ctl reconfigure.
But I rather like to get this working in a correct manner. Maybe somebody add at this shmmax statement above to the host /etc/sysctl.conf file?
Let me know if somebody can help me with this or which direction you want to go.
Ps. where are not the only one on the internet: http://letmegooglethat.com/?q=STDERR%3A+sysctl%3A+setting+key+%22kernel.shmm...
Thx!
Kind regards, Melroy van den Berg
On Di 09 Jun 2020 01:11:48 CEST, Melroy van den Berg wrote:
But I rather like to get this working in a correct manner. Maybe somebody add at this shmmax statement above to the host
/etc/sysctl.conf file?
Done + echo'ed to /proc/sys/kernel/shmmax.
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Hi,
I just discovered that GitLab tries to also set the following during "sysctl -e --system" command:
cat /etc/sysctl.d/90-omnibus-gitlab-kernel.sem.conf kernel.sem = 250 32000 32 262
And also:
cat /etc/sysctl.d/protect-links.conf ################################################################### # Protected links # # Protects against creating or following links under certain conditions # Debian kernels have both set to 1 (restricted) # See https://www.kernel.org/doc/Documentation/sysctl/fs.txt fs.protected_hardlinks = 1 fs.protected_symlinks = 1
You maybe want to change this as well in the host & container?
I disabled the command "reload all sysctrl conf" for now in in the GitLab recipes (Ruby code): /opt/gitlab/embedded/cookbooks/package/recipes/sysctl.rb
As well as, I commented-out where "reload all sysctrl conf" is used in: /opt/gitlab/embedded/cookbooks/package/resources/gitlab_sysctl.rb
I will create a GitLab issue or comment on an existing GitLab issue regarding support LXC containers without this much hassle.
Next issue I'm facing is regarding Let's Encrypt. But the terminal is now in use by somebody else...
Regards, Melroy van den Berg
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Op dinsdag, juni 9, 2020 5:56 AM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> schreef:
On Di 09 Jun 2020 01:11:48 CEST, Melroy van den Berg wrote:
But I rather like to get this working in a correct manner. Maybe somebody add at this shmmax statement above to the host > /etc/sysctl.conf file?
Done + echo'ed to /proc/sys/kernel/shmmax.
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Hello together,
I saw on last byobu session, that acme ipv6 was not successfull. gitlab.x2go.org is now rebooted and running apt-get -f install
Best Regards, Juri Grabowski
HI Melroy,
On Di 09 Jun 2020 23:01:24 CEST, Melroy van den Berg wrote:
Hi,
I just discovered that GitLab tries to also set the following during
"sysctl -e --system" command:cat /etc/sysctl.d/90-omnibus-gitlab-kernel.sem.conf kernel.sem = 250 32000 32 262
And also:
cat /etc/sysctl.d/protect-links.conf ################################################################### # Protected links # # Protects against creating or following links under certain conditions # Debian kernels have both set to 1 (restricted) # See https://www.kernel.org/doc/Documentation/sysctl/fs.txt fs.protected_hardlinks = 1 fs.protected_symlinks = 1
You maybe want to change this as well in the host & container?
I disabled the command "reload all sysctrl conf" for now in in the
GitLab recipes (Ruby code): /opt/gitlab/embedded/cookbooks/package/recipes/sysctl.rbAs well as, I commented-out where "reload all sysctrl conf" is used in: /opt/gitlab/embedded/cookbooks/package/resources/gitlab_sysctl.rb
I will create a GitLab issue or comment on an existing GitLab issue
regarding support LXC containers without this much hassle.Next issue I'm facing is regarding Let's Encrypt. But the terminal
is now in use by somebody else...Regards, Melroy van den Berg
I haven't got back to your mail, I am sorry.
Unfortunately, the host hosting gitlab.x2go.org has been taken offline
by the provide due to some NIC misconfiguration. We are investigating
on that.
I'd like to use gitlab.x2go.org starting next week for some new
projects related to X2Go. Melroy, do you think the system is already
usable (once it's online again)?
Sorry, for having not followed up on your work, but I was really busy
the last bit of June.
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Am 07.07.20 um 23:06 schrieb Mike Gabriel:
Unfortunately, the host hosting gitlab.x2go.org has been taken offline by the provide due to some NIC misconfiguration. We are investigating on that.
This is an issue on the host affecting IPv4 access to the host only - gitlab.x2go.org has a separate IPv4 (as requested during setup), and is working just fine.
IPv6 is unaffected as well.
I'd like to use gitlab.x2go.org starting next week for some new projects related to X2Go. Melroy, do you think the system is already usable (once it's online again)?
It has never been offline, at least SSH and HTTPS are working (HTTPS is using a self-signed cert, though).
@Mike: Do let us know what you intend to do there, please, before just going ahead. This isn't your company machine/personal box, so you should speak up before you act.
Kind Regards, Stefan Baur
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Hi Stefan,
On Di 07 Jul 2020 23:25:58 CEST, Stefan Baur wrote:
Am 07.07.20 um 23:06 schrieb Mike Gabriel:
I'd like to use gitlab.x2go.org starting next week for some new projects related to X2Go. Melroy, do you think the system is already usable (once it's online again)?
@Mike: Do let us know what you intend to do there, please, before just going ahead. This isn't your company machine/personal box, so you should speak up before you act.
As discussed off-list earlier, I plan to work on an X2Go WebUI like
project over the next three weeks together with two talented student
programmers.
Greets, Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Hi again,
On Di 07 Jul 2020 23:25:58 CEST, Stefan Baur wrote:
Am 07.07.20 um 23:06 schrieb Mike Gabriel:
Unfortunately, the host hosting gitlab.x2go.org has been taken offline by the provide due to some NIC misconfiguration. We are investigating on that.
This is an issue on the host affecting IPv4 access to the host only - gitlab.x2go.org has a separate IPv4 (as requested during setup), and is working just fine.
IPv6 is unaffected as well.
I'd like to use gitlab.x2go.org starting next week for some new projects related to X2Go. Melroy, do you think the system is already usable (once it's online again)?
It has never been offline, at least SSH and HTTPS are working (HTTPS is using a self-signed cert, though).
Currently, I cannot reach the LXC container via SSH. Neiter via IPv4 nor IPv6.
Funnily, I can reach the GitLab webinterface...
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Am 08.07.20 um 10:22 schrieb Mike Gabriel:
Currently, I cannot reach the LXC container via SSH. Neiter via IPv4 nor IPv6.
Funnily, I can reach the GitLab webinterface...
You might want to check your local end, then, as this works just fine here ... (obviously, I don't have the proper credentials to log in, but the connection itself works):
ssh -vvv gitlab.x2go.org OpenSSH_7.6p1 Ubuntu-4ubuntu0.3, OpenSSL 1.0.2n 7 Dec 2017 debug1: Reading configuration data /home/user/.ssh/config debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: resolving "gitlab.x2go.org" port 22 debug2: ssh_connect_direct: needpriv 0 debug1: Connecting to gitlab.x2go.org [188.40.111.169] port 22. debug1: Connection established. debug1: identity file /home/user/.ssh/id_rsa type 0 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_rsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_dsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_dsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_ecdsa type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_ecdsa-cert type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_ed25519 type -1 debug1: key_load_public: No such file or directory debug1: identity file /home/user/.ssh/id_ed25519-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 debug1: Remote protocol version 2.0, remote software version OpenSSH_7.9p1 Debian-10+deb10u2 debug1: match: OpenSSH_7.9p1 Debian-10+deb10u2 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to gitlab.x2go.org:22 as 'user' debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /home/user/.ssh/known_hosts:400 debug3: load_hostkeys: loaded 1 keys from gitlab.x2go.org debug3: order_hostkeyalgs: prefer hostkeyalgs: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521 debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib@openssh.com,zlib debug2: compression stoc: none,zlib@openssh.com,zlib debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 debug2: host key algorithms: rsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 debug2: ciphers ctos: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: ciphers stoc: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com debug2: MACs ctos: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib@openssh.com debug2: compression stoc: none,zlib@openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug1: kex: algorithm: curve25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: Server host key: ecdsa-sha2-nistp256 SHA256:/AqJEtVkq5qU6tDAFtHMs/X7RruaXSzRh1EcpF1w1h8 debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /home/user/.ssh/known_hosts:400 debug3: load_hostkeys: loaded 1 keys from gitlab.x2go.org debug3: hostkeys_foreach: reading file "/home/user/.ssh/known_hosts" debug3: record_hostkey: found key type ECDSA in file /home/user/.ssh/known_hosts:401 debug3: load_hostkeys: loaded 1 keys from 188.40.111.169 debug1: Host 'gitlab.x2go.org' is known and matches the ECDSA host key. debug1: Found key in /home/user/.ssh/known_hosts:400 debug3: send packet: type 21 debug2: set_newkeys: mode 1 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug1: SSH2_MSG_NEWKEYS received debug2: set_newkeys: mode 0 debug1: rekey after 134217728 blocks debug2: key: /home/user/.ssh/id_rsa (0x55e21f426a60) debug2: key: /home/user/.ssh/id_dsa ((nil)) debug2: key: /home/user/.ssh/id_ecdsa ((nil)) debug2: key: /home/user/.ssh/id_ed25519 ((nil)) debug3: send packet: type 5 debug3: receive packet: type 7 debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: RSA SHA256:9Cx8z15xZF/Za1AuKgfgHboK3IaMNl+8xF1aUWN3fsI /home/user/.ssh/id_rsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password debug1: Trying private key: /home/user/.ssh/id_dsa debug3: no such identity: /home/user/.ssh/id_dsa: No such file or directory debug1: Trying private key: /home/user/.ssh/id_ecdsa debug3: no such identity: /home/user/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /home/user/.ssh/id_ed25519 debug3: no such identity: /home/user/.ssh/id_ed25519: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password user@gitlab.x2go.org's password:
-Stefan
-- BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243
Hi Mike and others,
The latest state is that the installation is indeed working except the httpS (SSL) by Let's Encrypt. For some reason the installation fails to authenticate/verify itself correctly to the Let's encrypt server. Normally this works fine, and you will get a free Let's Encrypt certificate that is used by GitLab instance. For now the instance is using a self-signed certificate (which is not ideal).
You can execute: 'gitlab-ctl reconfigure' on the VM to trigger a certificate deployment of Let's Encrypt. Maybe somebody knows why is goes wrong in this VM?
More info: https://docs.gitlab.com/omnibus/settings/ssl.html
Off-topic: Too bad I also hurt by wrist, so that is why I take it a bit easy now. Sorry about that, a wrist injury is taking some time to heal again. :\
Kind regards, Melroy van den Berg
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Op dinsdag, juli 7, 2020 11:06 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> schreef:
HI Melroy,
On Di 09 Jun 2020 23:01:24 CEST, Melroy van den Berg wrote:
Hi, I just discovered that GitLab tries to also set the following during > "sysctl -e --system" command: cat /etc/sysctl.d/90-omnibus-gitlab-kernel.sem.conf kernel.sem = 250 32000 32 262 And also: cat /etc/sysctl.d/protect-links.conf ###################################################################
Protected links
================
==
Protects against creating or following links under certain conditions
======================================================================
Debian kernels have both set to 1 (restricted)
===============================================
See https://www.kernel.org/doc/Documentation/sysctl/fs.txt
===========================================================
fs.protected_hardlinks = 1 fs.protected_symlinks = 1 You maybe want to change this as well in the host & container? I disabled the command "reload all sysctrl conf" for now in in the > GitLab recipes (Ruby code): /opt/gitlab/embedded/cookbooks/package/recipes/sysctl.rb As well as, I commented-out where "reload all sysctrl conf" is used in: /opt/gitlab/embedded/cookbooks/package/resources/gitlab_sysctl.rb I will create a GitLab issue or comment on an existing GitLab issue > regarding support LXC containers without this much hassle. Next issue I'm facing is regarding Let's Encrypt. But the terminal > is now in use by somebody else... Regards, Melroy van den Berg
I haven't got back to your mail, I am sorry.
Unfortunately, the host hosting gitlab.x2go.org has been taken offline by the provide due to some NIC misconfiguration. We are investigating on that.
I'd like to use gitlab.x2go.org starting next week for some new projects related to X2Go. Melroy, do you think the system is already usable (once it's online again)?
Sorry, for having not followed up on your work, but I was really busy the last bit of June.
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
Hi,
any progress on this?
Uli
On Tue, Jul 14, 2020 at 6:58 PM Melroy van den Berg <melroy89@protonmail.com> wrote:
Hi Mike and others,
The latest state is that the installation is indeed working except the httpS (SSL) by Let's Encrypt. For some reason the installation fails to authenticate/verify itself correctly to the Let's encrypt server. Normally this works fine, and you will get a free Let's Encrypt certificate that is used by GitLab instance. For now the instance is using a self-signed certificate (which is not ideal).
You can execute: 'gitlab-ctl reconfigure' on the VM to trigger a certificate deployment of Let's Encrypt. Maybe somebody knows why is goes wrong in this VM?
More info: https://docs.gitlab.com/omnibus/settings/ssl.html
Off-topic: Too bad I also hurt by wrist, so that is why I take it a bit easy now. Sorry about that, a wrist injury is taking some time to heal again. :\
Kind regards, Melroy van den Berg
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Op dinsdag, juli 7, 2020 11:06 PM, Mike Gabriel <mike.gabriel@das-netzwerkteam.de> schreef:
HI Melroy,
On Di 09 Jun 2020 23:01:24 CEST, Melroy van den Berg wrote:
Hi, I just discovered that GitLab tries to also set the following during > "sysctl -e --system" command: cat /etc/sysctl.d/90-omnibus-gitlab-kernel.sem.conf kernel.sem = 250 32000 32 262 And also: cat /etc/sysctl.d/protect-links.conf ###################################################################
Protected links
================
==
Protects against creating or following links under certain conditions
======================================================================
Debian kernels have both set to 1 (restricted)
===============================================
See https://www.kernel.org/doc/Documentation/sysctl/fs.txt
===========================================================
fs.protected_hardlinks = 1 fs.protected_symlinks = 1 You maybe want to change this as well in the host & container? I disabled the command "reload all sysctrl conf" for now in in the > GitLab recipes (Ruby code): /opt/gitlab/embedded/cookbooks/package/recipes/sysctl.rb As well as, I commented-out where "reload all sysctrl conf" is used in: /opt/gitlab/embedded/cookbooks/package/resources/gitlab_sysctl.rb I will create a GitLab issue or comment on an existing GitLab issue > regarding support LXC containers without this much hassle. Next issue I'm facing is regarding Let's Encrypt. But the terminal > is now in use by somebody else... Regards, Melroy van den Berg
I haven't got back to your mail, I am sorry.
Unfortunately, the host hosting gitlab.x2go.org has been taken offline by the provide due to some NIC misconfiguration. We are investigating on that.
I'd like to use gitlab.x2go.org starting next week for some new projects related to X2Go. Melroy, do you think the system is already usable (once it's online again)?
Sorry, for having not followed up on your work, but I was really busy the last bit of June.
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Hi Uli and the rest,
I know that Stefan has some personal issues several months ago. Hopefully he is able to push GitLab towards production and have everybody aligned.
I'm ready when you are.
See the wiki page for the work packages I identified so far: https://wiki.x2go.org/doku.php/wiki:development:gitlab
There is one issue... I noticed that the server is down? https://gitlab.x2go.org/
I was also unable to ping 188.40.111.169.
Which is not a good sign?... somebody?
Regards, Melroy van den Berg melroy89@pm.me
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Op donderdag, april 1, 2021 1:59 PM, Ulrich Sibiller <ulrich.sibiller@gmail.com> schreef:
Hi,
any progress on this?
Uli
On Tue, Jul 14, 2020 at 6:58 PM Melroy van den Berg melroy89@protonmail.com wrote:
Hi Mike and others, The latest state is that the installation is indeed working except the httpS (SSL) by Let's Encrypt. For some reason the installation fails to authenticate/verify itself correctly to the Let's encrypt server. Normally this works fine, and you will get a free Let's Encrypt certificate that is used by GitLab instance. For now the instance is using a self-signed certificate (which is not ideal). You can execute: 'gitlab-ctl reconfigure' on the VM to trigger a certificate deployment of Let's Encrypt. Maybe somebody knows why is goes wrong in this VM? More info: https://docs.gitlab.com/omnibus/settings/ssl.html Off-topic: Too bad I also hurt by wrist, so that is why I take it a bit easy now. Sorry about that, a wrist injury is taking some time to heal again. :
Kind regards, Melroy van den Berg ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ Op dinsdag, juli 7, 2020 11:06 PM, Mike Gabriel mike.gabriel@das-netzwerkteam.de schreef:HI Melroy, On Di 09 Jun 2020 23:01:24 CEST, Melroy van den Berg wrote:
Hi, I just discovered that GitLab tries to also set the following during > "sysctl -e --system" command: cat /etc/sysctl.d/90-omnibus-gitlab-kernel.sem.conf kernel.sem = 250 32000 32 262 And also: cat /etc/sysctl.d/protect-links.conf ################################################################### Protected links
== Protects against creating or following links under certain conditions
Debian kernels have both set to 1 (restricted)
See https://www.kernel.org/doc/Documentation/sysctl/fs.txt
fs.protected_hardlinks = 1 fs.protected_symlinks = 1 You maybe want to change this as well in the host & container? I disabled the command "reload all sysctrl conf" for now in in the > GitLab recipes (Ruby code): /opt/gitlab/embedded/cookbooks/package/recipes/sysctl.rb As well as, I commented-out where "reload all sysctrl conf" is used in: /opt/gitlab/embedded/cookbooks/package/resources/gitlab_sysctl.rb I will create a GitLab issue or comment on an existing GitLab issue > regarding support LXC containers without this much hassle. Next issue I'm facing is regarding Let's Encrypt. But the terminal > is now in use by somebody else... Regards, Melroy van den Berg
I haven't got back to your mail, I am sorry. Unfortunately, the host hosting gitlab.x2go.org has been taken offline by the provide due to some NIC misconfiguration. We are investigating on that. I'd like to use gitlab.x2go.org starting next week for some new projects related to X2Go. Melroy, do you think the system is already usable (once it's online again)? Sorry, for having not followed up on your work, but I was really busy the last bit of June. Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940 GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
x2go-dev mailing list x2go-dev@lists.x2go.org https://lists.x2go.org/listinfo/x2go-dev
Hi all,
that was the point not to use https://fasttrack.debian.net/ for gitlab?
Best Regards, Juri Grabowski
Hi Juri,
On Mo 15 Jun 2020 23:36:09 CEST, x2go-dev wrote:
Hi all,
that was the point not to use https://fasttrack.debian.net/ for gitlab?
s/that/What/ ?
Best Regards, Juri Grabowski
I use the fasttrack GitLab and one main disadvantage is the missing
gitlabctl command that the omnibus GitLab has.
Furthermore, I regularly bump into issues with upgrades of the
fasttrack GitLab. Then I ask Pirate Praveen (the maintainer) and he
always has a solution, but...
So fasttrack GitLab basically works well, but I slightly prefer the
upstream-supported Omnibus DEB installation.
No big deal of a difference, but slightly more comfortable.
Mike
DAS-NETZWERKTEAM c\o Technik- und Ökologiezentrum Eckernförde Mike Gabriel, Marienthaler Str. 17, 24340 Eckernförde mobile: +49 (1520) 1976 148 landline: +49 (4351) 850 8940
GnuPG Fingerprint: 9BFB AEE8 6C0A A5FF BF22 0782 9AF4 6B30 2577 1B31 mail: mike.gabriel@das-netzwerkteam.de, http://das-netzwerkteam.de
On 2020-06-15 23:36 1, x2go-dev@jugra.de wrote:
that was the point not to use https://fasttrack.debian.net/ for gitlab? OK, it doesn't look like production ready. Self with deb https://people.debian.org/~praveen/gitaly buster-backports main contrib deb https://people.debian.org/~praveen/gitlab buster-fasttrack main contrib repos
-
Melroy van den Berg -
Mike Gabriel -
Stefan Baur -
Ulrich Sibiller -
x2go-dev＠jugra.de