opticon

Members
  • Posts

    34
  • Joined

  • Last visited

Everything posted by opticon

  1. I need to use macvlan as I've got multiple networks
  2. Just swapped the RAM out again with 2x sticks that I've never used before and it crashes straight after booting Nov 18 08:40:38 Nemesis kernel: ------------[ cut here ]------------ Nov 18 08:40:38 Nemesis kernel: WARNING: CPU: 0 PID: 23353 at net/netfilter/nf_conntrack_core.c:1210 __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Nov 18 08:40:38 Nemesis kernel: Modules linked in: bluetooth ecdh_generic ecc wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha xt_mark xt_CHECKSUM ipt_REJECT nf_reject_ipv4 ip6table_mangle ip6table_nat iptable_mangle vhost_net tun vhost vhost_iotlb tap macvlan veth xt_nat xt_tcpudp xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 xt_addrtype br_netfilter xfs md_mod tcp_diag inet_diag af_packet it87 hwmon_vid ip6table_filter ip6_tables iptable_filter ip_tables x_tables 8021q garp mrp bridge stp llc bonding tls e1000e alx mdio zfs(PO) zunicode(PO) zzstd(O) intel_rapl_msr intel_rapl_common x86_pkg_temp_thermal zlua(O) intel_powerclamp i915 zavl(PO) coretemp icp(PO) kvm_intel zcommon(PO) znvpair(PO) kvm spl(O) iosf_mbi crct10dif_pclmul crc32_pclmul drm_buddy i2c_algo_bit crc32c_intel ttm ghash_clmulni_intel sha512_ssse3 aesni_intel Nov 18 08:40:38 Nemesis kernel: drm_display_helper crypto_simd cryptd drm_kms_helper rapl intel_cstate mei_hdcp mei_pxp drm intel_uncore ahci intel_gtt i2c_i801 i2c_smbus libahci mei_me agpgart mei input_leds i2c_core syscopyarea led_class cdc_acm sysfillrect sysimgblt fb_sys_fops video thermal fan wmi backlight acpi_pad button acpi_cpufreq unix [last unloaded: e1000e] Nov 18 08:40:38 Nemesis kernel: CPU: 0 PID: 23353 Comm: kworker/u8:0 Tainted: P O 6.1.49-Unraid #1 Nov 18 08:40:38 Nemesis kernel: Hardware name: Gigabyte Technology Co., Ltd. H97N-WIFI/H97N-WIFI, BIOS F9b 03/03/2016 Nov 18 08:40:38 Nemesis kernel: Workqueue: events_unbound macvlan_process_broadcast [macvlan] Nov 18 08:40:38 Nemesis kernel: RIP: 0010:__nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Nov 18 08:40:38 Nemesis kernel: Code: 44 24 10 e8 e2 e1 ff ff 8b 7c 24 04 89 ea 89 c6 89 04 24 e8 7e e6 ff ff 84 c0 75 a2 48 89 df e8 9b e2 ff ff 85 c0 89 c5 74 18 <0f> 0b 8b 34 24 8b 7c 24 04 e8 18 dd ff ff e8 93 e3 ff ff e9 72 01 Nov 18 08:40:38 Nemesis kernel: RSP: 0018:ffffc90000003d98 EFLAGS: 00010202 Nov 18 08:40:38 Nemesis kernel: RAX: 0000000000000001 RBX: ffff8881919d0500 RCX: 6c49c93b03265be6 Nov 18 08:40:38 Nemesis kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8881919d0500 Nov 18 08:40:38 Nemesis kernel: RBP: 0000000000000001 R08: 7af53b18c069d652 R09: 4867bc0d02b3bdb8 Nov 18 08:40:38 Nemesis kernel: R10: 5e14506fc4f298cc R11: ffffc90000003d60 R12: ffffffff82a11d00 Nov 18 08:40:38 Nemesis kernel: R13: 00000000000393bb R14: ffff88818cec7f00 R15: 0000000000000000 Nov 18 08:40:38 Nemesis kernel: FS: 0000000000000000(0000) GS:ffff888216a00000(0000) knlGS:0000000000000000 Nov 18 08:40:38 Nemesis kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Nov 18 08:40:38 Nemesis kernel: CR2: 000014cf98b99060 CR3: 00000001f3570005 CR4: 00000000001706f0 Nov 18 08:40:38 Nemesis kernel: Call Trace: Nov 18 08:40:38 Nemesis kernel: <IRQ> Nov 18 08:40:38 Nemesis kernel: ? __warn+0xab/0x122 Nov 18 08:40:38 Nemesis kernel: ? report_bug+0x109/0x17e Nov 18 08:40:38 Nemesis kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Nov 18 08:40:38 Nemesis kernel: ? handle_bug+0x41/0x6f Nov 18 08:40:38 Nemesis kernel: ? exc_invalid_op+0x13/0x60 Nov 18 08:40:38 Nemesis kernel: ? asm_exc_invalid_op+0x16/0x20 Nov 18 08:40:38 Nemesis kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Nov 18 08:40:38 Nemesis kernel: ? __nf_conntrack_confirm+0x9e/0x2b0 [nf_conntrack] Nov 18 08:40:38 Nemesis kernel: ? nf_nat_inet_fn+0x60/0x1a8 [nf_nat] Nov 18 08:40:38 Nemesis kernel: nf_conntrack_confirm+0x25/0x54 [nf_conntrack] Nov 18 08:40:38 Nemesis kernel: nf_hook_slow+0x3d/0x96 Nov 18 08:40:38 Nemesis kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Nov 18 08:40:38 Nemesis kernel: NF_HOOK.constprop.0+0x79/0xd9 Nov 18 08:40:38 Nemesis kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Nov 18 08:40:38 Nemesis kernel: __netif_receive_skb_one_core+0x77/0x9c Nov 18 08:40:38 Nemesis kernel: process_backlog+0x8c/0x116 Nov 18 08:40:38 Nemesis kernel: __napi_poll.constprop.0+0x2b/0x124 Nov 18 08:40:38 Nemesis kernel: net_rx_action+0x159/0x24f Nov 18 08:40:38 Nemesis kernel: __do_softirq+0x129/0x288 Nov 18 08:40:38 Nemesis kernel: do_softirq+0x7f/0xab Nov 18 08:40:38 Nemesis kernel: </IRQ> Nov 18 08:40:38 Nemesis kernel: <TASK> Nov 18 08:40:38 Nemesis kernel: __local_bh_enable_ip+0x4c/0x6b Nov 18 08:40:38 Nemesis kernel: netif_rx+0x52/0x5a Nov 18 08:40:38 Nemesis kernel: macvlan_broadcast+0x10a/0x150 [macvlan] Nov 18 08:40:38 Nemesis kernel: ? _raw_spin_unlock+0x14/0x29 Nov 18 08:40:38 Nemesis kernel: macvlan_process_broadcast+0xbc/0x12f [macvlan] Nov 18 08:40:38 Nemesis kernel: process_one_work+0x1ab/0x295 Nov 18 08:40:38 Nemesis kernel: worker_thread+0x18b/0x244 Nov 18 08:40:38 Nemesis kernel: ? rescuer_thread+0x281/0x281 Nov 18 08:40:38 Nemesis kernel: kthread+0xe7/0xef Nov 18 08:40:38 Nemesis kernel: ? kthread_complete_and_exit+0x1b/0x1b Nov 18 08:40:38 Nemesis kernel: ret_from_fork+0x22/0x30 Nov 18 08:40:38 Nemesis kernel: </TASK> Nov 18 08:40:38 Nemesis kernel: ---[ end trace 0000000000000000 ]---
  3. I rebuilt the 2 ZFS SSD cache pools and this is the latest the latest kernel trace, this looks to be network hardware or driver related? It seemed to happy 20mins after I re-installed my docker containers Nov 17 22:27:57 Nemesis kernel: ------------[ cut here ]------------ Nov 17 22:27:57 Nemesis kernel: WARNING: CPU: 2 PID: 20471 at net/netfilter/nf_conntrack_core.c:1210 __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Nov 17 22:27:57 Nemesis kernel: Modules linked in: bluetooth ecdh_generic ecc wireguard curve25519_x86_64 libcurve25519_generic libchacha20poly1305 chacha_x86_64 poly1305_x86_64 ip6_udp_tunnel udp_tunnel libchacha xt_mark veth xt_nat macvlan nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype br_netfilter xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp ip6table_mangle ip6table_nat iptable_mangle iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 vhost_net tun vhost vhost_iotlb tap md_mod reiserfs xfs tcp_diag inet_diag af_packet it87 hwmon_vid ip6table_filter ip6_tables iptable_filter ip_tables x_tables 8021q garp mrp bridge stp llc bonding tls e1000e alx mdio zfs(PO) zunicode(PO) zzstd(O) zlua(O) intel_rapl_msr zavl(PO) intel_rapl_common icp(PO) x86_pkg_temp_thermal intel_powerclamp i915 coretemp zcommon(PO) kvm_intel znvpair(PO) spl(O) kvm iosf_mbi drm_buddy crct10dif_pclmul i2c_algo_bit crc32_pclmul ttm crc32c_intel ghash_clmulni_intel sha512_ssse3 Nov 17 22:27:57 Nemesis kernel: mei_hdcp mei_pxp drm_display_helper drm_kms_helper drm aesni_intel crypto_simd cryptd rapl intel_cstate intel_uncore i2c_i801 intel_gtt i2c_smbus ahci libahci mei_me agpgart cdc_acm i2c_core input_leds mei led_class syscopyarea sysfillrect sysimgblt fb_sys_fops video fan thermal wmi backlight acpi_pad button acpi_cpufreq unix [last unloaded: md_mod] Nov 17 22:27:57 Nemesis kernel: CPU: 2 PID: 20471 Comm: Plex Transcoder Tainted: P O 6.1.49-Unraid #1 Nov 17 22:27:57 Nemesis kernel: Hardware name: Gigabyte Technology Co., Ltd. H97N-WIFI/H97N-WIFI, BIOS F9b 03/03/2016 Nov 17 22:27:57 Nemesis kernel: RIP: 0010:__nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Nov 17 22:27:57 Nemesis kernel: Code: 44 24 10 e8 e2 e1 ff ff 8b 7c 24 04 89 ea 89 c6 89 04 24 e8 7e e6 ff ff 84 c0 75 a2 48 89 df e8 9b e2 ff ff 85 c0 89 c5 74 18 <0f> 0b 8b 34 24 8b 7c 24 04 e8 18 dd ff ff e8 93 e3 ff ff e9 72 01 Nov 17 22:27:57 Nemesis kernel: RSP: 0000:ffffc90003fc3808 EFLAGS: 00010202 Nov 17 22:27:57 Nemesis kernel: RAX: 0000000000000001 RBX: ffff8882782b0400 RCX: 07fce6acd7c5d903 Nov 17 22:27:57 Nemesis kernel: RDX: 0000000000000000 RSI: 0000000000000001 RDI: ffff8882782b0400 Nov 17 22:27:57 Nemesis kernel: RBP: 0000000000000001 R08: 479ac0e25f22a2fa R09: aaba1118c5017bd7 Nov 17 22:27:57 Nemesis kernel: R10: 22a15cc915a5bd30 R11: ffffc90003fc37d0 R12: ffffffff82a11d00 Nov 17 22:27:57 Nemesis kernel: R13: 000000000001ff9d R14: ffff888298b8f000 R15: 0000000000000000 Nov 17 22:27:57 Nemesis kernel: FS: 0000154c5353c808(0000) GS:ffff88840eb00000(0000) knlGS:0000000000000000 Nov 17 22:27:57 Nemesis kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Nov 17 22:27:57 Nemesis kernel: CR2: 0000154c50285000 CR3: 000000026772c005 CR4: 00000000001706e0 Nov 17 22:27:57 Nemesis kernel: Call Trace: Nov 17 22:27:57 Nemesis kernel: <TASK> Nov 17 22:27:57 Nemesis kernel: ? __warn+0xab/0x122 Nov 17 22:27:57 Nemesis kernel: ? report_bug+0x109/0x17e Nov 17 22:27:57 Nemesis kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Nov 17 22:27:57 Nemesis kernel: ? handle_bug+0x41/0x6f Nov 17 22:27:57 Nemesis kernel: ? exc_invalid_op+0x13/0x60 Nov 17 22:27:57 Nemesis kernel: ? asm_exc_invalid_op+0x16/0x20 Nov 17 22:27:57 Nemesis kernel: ? __nf_conntrack_confirm+0xa4/0x2b0 [nf_conntrack] Nov 17 22:27:57 Nemesis kernel: ? __nf_conntrack_confirm+0x9e/0x2b0 [nf_conntrack] Nov 17 22:27:57 Nemesis kernel: ? nf_nat_inet_fn+0x126/0x1a8 [nf_nat] Nov 17 22:27:57 Nemesis kernel: nf_conntrack_confirm+0x25/0x54 [nf_conntrack] Nov 17 22:27:57 Nemesis kernel: nf_hook_slow+0x3d/0x96 Nov 17 22:27:57 Nemesis kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Nov 17 22:27:57 Nemesis kernel: NF_HOOK.constprop.0+0x79/0xd9 Nov 17 22:27:57 Nemesis kernel: ? ip_protocol_deliver_rcu+0x164/0x164 Nov 17 22:27:57 Nemesis kernel: ip_sabotage_in+0x52/0x60 [br_netfilter] Nov 17 22:27:57 Nemesis kernel: nf_hook_slow+0x3d/0x96 Nov 17 22:27:57 Nemesis kernel: ? ip_rcv_finish_core.constprop.0+0x3e8/0x3e8 Nov 17 22:27:57 Nemesis kernel: NF_HOOK.constprop.0+0x79/0xd9 Nov 17 22:27:57 Nemesis kernel: ? ip_rcv_finish_core.constprop.0+0x3e8/0x3e8 Nov 17 22:27:57 Nemesis kernel: __netif_receive_skb_one_core+0x77/0x9c Nov 17 22:27:57 Nemesis kernel: netif_receive_skb+0xbf/0x127 Nov 17 22:27:57 Nemesis kernel: br_handle_frame_finish+0x438/0x472 [bridge] Nov 17 22:27:57 Nemesis kernel: ? br_pass_frame_up+0xdd/0xdd [bridge] Nov 17 22:27:57 Nemesis kernel: br_nf_hook_thresh+0xe5/0x109 [br_netfilter] Nov 17 22:27:57 Nemesis kernel: ? br_pass_frame_up+0xdd/0xdd [bridge] Nov 17 22:27:57 Nemesis kernel: br_nf_pre_routing_finish+0x2c1/0x2ec [br_netfilter] Nov 17 22:27:57 Nemesis kernel: ? br_pass_frame_up+0xdd/0xdd [bridge] Nov 17 22:27:57 Nemesis kernel: ? NF_HOOK.isra.0+0xe4/0x140 [br_netfilter] Nov 17 22:27:57 Nemesis kernel: ? br_nf_hook_thresh+0x109/0x109 [br_netfilter] Nov 17 22:27:57 Nemesis kernel: br_nf_pre_routing+0x236/0x24a [br_netfilter] Nov 17 22:27:57 Nemesis kernel: ? br_nf_hook_thresh+0x109/0x109 [br_netfilter] Nov 17 22:27:57 Nemesis kernel: br_handle_frame+0x27a/0x2e0 [bridge] Nov 17 22:27:57 Nemesis kernel: ? br_pass_frame_up+0xdd/0xdd [bridge] Nov 17 22:27:57 Nemesis kernel: __netif_receive_skb_core.constprop.0+0x4fd/0x6e9 Nov 17 22:27:57 Nemesis kernel: ? __build_skb+0x20/0x4e Nov 17 22:27:57 Nemesis kernel: ? kmem_cache_alloc+0x122/0x14d Nov 17 22:27:57 Nemesis kernel: __netif_receive_skb_list_core+0x8a/0x11e Nov 17 22:27:57 Nemesis kernel: netif_receive_skb_list_internal+0x1d2/0x20b Nov 17 22:27:57 Nemesis kernel: gro_normal_list+0x1d/0x3f Nov 17 22:27:57 Nemesis kernel: napi_complete_done+0x7b/0x11a Nov 17 22:27:57 Nemesis kernel: e1000e_poll+0x9e/0x23e [e1000e] Nov 17 22:27:57 Nemesis kernel: __napi_poll.constprop.0+0x2b/0x124 Nov 17 22:27:57 Nemesis kernel: net_rx_action+0x159/0x24f Nov 17 22:27:57 Nemesis kernel: __do_softirq+0x129/0x288 Nov 17 22:27:57 Nemesis kernel: __irq_exit_rcu+0x5e/0xb8 Nov 17 22:27:57 Nemesis kernel: common_interrupt+0x3b/0xc1 Nov 17 22:27:57 Nemesis kernel: asm_common_interrupt+0x22/0x40 Nov 17 22:27:57 Nemesis kernel: RIP: 0033:0x154c5284d156 Nov 17 22:27:57 Nemesis kernel: Code: ff 8b 45 00 01 c0 f7 d0 41 89 c7 41 c1 ff 1f 41 31 c7 45 89 fd 48 8b 4c 24 30 41 d3 fd 48 83 c5 04 41 8d 45 01 3d ff ff ff 7f <48> 89 6c 24 18 0f 85 8f 00 00 00 bd 1e 00 00 80 4c 8b 6c 24 10 eb Nov 17 22:27:57 Nemesis kernel: RSP: 002b:00007ffd82b98140 EFLAGS: 00000293 Nov 17 22:27:57 Nemesis kernel: RAX: 0000000000000001 RBX: 0000000000041fb8 RCX: 0000000000000009 Nov 17 22:27:57 Nemesis kernel: RDX: 0000000000000009 RSI: 4b76378fbaadbe88 RDI: 0000154c4f39d308 Nov 17 22:27:57 Nemesis kernel: RBP: 0000154c4f840560 R08: 0000154c4f39d320 R09: 0000000000000030 Nov 17 22:27:57 Nemesis kernel: R10: 12ecea4610d7f930 R11: 0000154c4f7aeb6c R12: 0000154c4f39d310 Nov 17 22:27:57 Nemesis kernel: R13: 0000000000000000 R14: 0000000000000030 R15: 00000000000000fa Nov 17 22:27:57 Nemesis kernel: </TASK> Nov 17 22:27:57 Nemesis kernel: ---[ end trace 0000000000000000 ]--- nemesis-diagnostics-20231118-0753.zip
  4. memtest passed twice with no errors. I started up again and came accross and error that lead me to these links. I've been able to mount ZFS as read-only and copying the data to the array and then I'll re-create the ZFS pool and monitor for a couple of days.
  5. I swapped to ZFS pools about a month ago because BTFRS was giving me corruption issues because of the server crashes I've had memtest freeze on my once (screenshot attached) but since I restarted it, it's completed 1 pass against all CPU cores with 0 errors. It's just over half way through the 2nd again. I swapped the 2x RAM sticks approx 2 months ago when it 1st staretd crashing and it seemed to be fine for a month until it started again. I'm starting to think it's either the board or the CPU now (both are now 10yrs old and been running 24/7 for probably 8yrs)
  6. Over the last 2-3 months I've had issues with unraid randomly stalling (web UI sorta works but very slow, docker containers stop responding) and complete crashes ( What I mean by stalling: unraid mgmt web interface works but dashboard stats won't work Restarting docker containers via web interface just spins around SSH responds but hangs when lauching htop It hangs when Initiating a clean reboot/shutdown What i mean by crashes: I've been seeing kernel panics show up in the syslog (but not every time it crashes) See attached for a example Once I reboot the server, sometimes it will crash again during startup or it will work fine for someones only an hour or 2-3 days. I've tried shutting down all containers and only starting them up 1 by 1 each day but haven't been able to figure a cause. Memtest seems to be ok I've uploaded my diagnostics if anyone can take a look and point me in the right direction? nemesis-diagnostics-20231116-0840.zip kernel panic.txt
  7. I searched the thread but couldnt' see anything similar, this doesn't seem to work well with macvlan networks after a reboot I'm running LibreNMS thought a compose file with each container having a static IP on a vlan that's different from the host. Nothing starts after a reboot. If I try to run 'Compose up' after a reboot I get the following: [+] Running 4/8 ⠿ Container librenms_msmtpd Starting 0.1s ⠿ Container librenms_db Starting 0.1s ⠿ Container librenms_memcached Starting 0.1s ⠿ Container librenms Created 0.0s ⠿ Container librenms_snmptrapd Created 0.0s ⠿ Container librenms_redis Starting 0.1s ⠿ Container librenms_dispatcher Created 0.0s ⠿ Container librenms_syslogng Created 0.0s Error response from daemon: network 01b3083bfada0eacc06028b994c51fcee636dfa299ca5742895ff5cdc27aca3a not found If I click 'Compose Down' and wait for that to complete and then run 'Compose Up' everything starts up fine. Any ideas?
  8. It works thankyou Running a full benchmark on everything now
  9. Hi @jbartlett, Thanks for putting the docker together, I've got it installed on 2x unRAID boxes and 1 works fine but the other does not. Motherboard: Asus B85M-E HBA: H310 (flashed to LSI HBA mode) The SSD's where originally connected to the HBA but I've moved them to the onboard SATA controller and I get the same error message. I think the SSD make/model being identical up until the last 3 digits might be the issue? Any help would be appreciated
  10. I'm currently working on a ZT docker that will allow you to route to internal networks, I'm testing it in bridge mode (container with it's own IP). It's a fork of someone else's which I'll write a config for UnRAID. It's a best effort thing only right now and I'll try to finish it asap. One thing I discovered while testing my docker, as your internal network clients usually get an DHCP IP Address from your router. Your router actually has no idea about the ZT network. So you'll need to log onto your firewall and create a route to send all ZT network traffic to the IP Address of your docker container. i.e # Variables Internal Network: 192.168.1.0/24 Internal router: 192.168.1.1 Container IP: 192.168.1.11 ZeroTier Network: 172.16.0.0/16 ZeroTier Container IP: 172.16.12.50 # ZeroTier Managed Route Destination: 192.168.0.0/24 (ZT's network) Via: 172.16.12.50 (ZT container IP) Now click on the Spanner icon for your device in the ZT Web console and click 'Allow Ethernet Bridging' # Firewall Router rule Subnet: 172.16.0.0/16 (ZT Network range) Gateway: 192.168.1.11 (ZT Container IP Address)
  11. I think that might be because your on the light theme? I've just left mine at the new default dark theme. If there's a fix etc let me know. First time posting with this new forum so I don't know if it's a issue for everyone etc
  12. @malvarez00 Any idea when you can commit @aartr's fix so we don't have to do the workarounds?
  13. So your getting the unraid Main page? What port have you assigned to the gitlab HTTP and HTTPS Port? The docker ports are what you need to set the proxy_pass URL line to Perhaps post your config and redacted IP's and if your using the docker in host mode or IP mode etc and we can help you from there
  14. I was testing you all to see if you followed the instructions I do have that as well actually, I just forgot to put it in the instructions!
  15. Are you using the exernal letsencrypt/nginx docker or the built in one to access gitlab? I run gitlab from it's own subdomain and best practice is to do just that, if at all possible it would be easier for you to change your config to git.mydomain.bla From what I understand, your wanting to change the relative root path for gitlab, it's not something I've done but going by the link below you just need to change your setting to: --env GITLAB_OMNIBUS_CONFIG="external_url 'https://mydomain.bla:9080/gitlab" If that doesn't work, try removing the port number and giving nginx it's own param to listen on a different port. I know the doco says it's supported but I've always run mine separately --env GITLAB_OMNIBUS_CONFIG="external_url 'https://mydomain.bla/gitlab'"; nginx['listen_port'] = 9080; Official gitlab support doc, using the built in nginx server. https://docs.gitlab.com/omnibus/settings/configuration.html#configuring-a-relative-url-for-gitlab
  16. Here's some instructions on how to configure GitLab-rake to create its backups and automatically purging backups older than 31 days ##### How to configure GitLab-CE docker to run rake backups Summary The following steps will create a dedicated backup folder for gitlab rake to export the backups to and automatically purge backups older than 31 days. If you wish, you can use the default folder and time to keep backups by removing the config lines so it uses the defaults from gitlab.rb This backs up the REPOSITORY DATA ONLY and not your configuration/secret files etc. Use CA Backup/Restore or another method for backing up those files under the appdata/gitlab-ce folder You should already have the CA User Scripts plugin installed to create the backup script and allow you to schedule it to run automatically. References: https://docs.gitlab.com/ee/raketasks/backup_restore.html https://docs.gitlab.com/omnibus/settings/backups.html Steps 1. Create a folder called 'backups' on the unraid host: mkdir /mnt/user/appdata/gitlab-ce/backups 2. Edit the gitlab-ce docker, open advanced settings and edit the 'Extra Parameters:' section and paste in the following text. Don't forget to paste it before the last double-quote symbol. Copy and paste it all to notepad if that makes it easier and then copy it back to the webpage. gitlab_rails['manage_backup_path'] = true; gitlab_rails['backup_path'] = '/backups'; gitlab_rails['backup_archive_permissions'] = 0644; gitlab_rails['backup_pg_schema'] = 'public'; gitlab_rails['backup_keep_time'] = 2678400; 3. Go to the User.Scripts plugin page and create a new script, call it: Backup-Gitlab. Click on the script name in the webpage and select ‘edit script’ and copy/paste the following text into it: echo ”Backup is starting” docker exec -t GitLab-CE gitlab-rake gitlab:backup:create echo ”Backup has completed” I like to give my scripts descriptions; here’s mine: Use docker exec to perform gitlab rake backups 4. Run the script manually and don’t close the window until you see the text: “Backup has completed’. Go to the folder in your unraid SSH session and verify the files where created through SSH under /mnt/user/appdata/gitlab-ce/backups 5. Click on the ‘Scheduled Disabled’ menu option in user.scripts and set it to whatever you like. If you run CA Backup/Restore, make sure it’s not going to be running at the same time as this script, otherwise it won’t work because gitlab will be shutdown 6. Apply the user.script config and go to bed. Check your server the next day for the rake backups, you won’t have access to the backup’s folder via network sharing so use SSH to verify the file is there under /appdata/gitlab-ce/backups
  17. Sorry I missed the other guys post, can you attach a copy of your nginx conf file, docker/gitlab log after it's started/fully running and a copy of the extra params your using? Remember to rename your domain etc to just genericdomain.com or something
  18. From what I understand you shouldn't edit gitlab.rb at all, it WILL get destroyed on the next update. You need to put all config you want to override in the extra params section in the unraid gitlab docker config page. I have all the stuff I mentioned plus more in a single like and it works fine
  19. Are you using your ISP SMTP server? does it 100% require auth? If so you may need to set it. I have 'true' in quotes for my config, which is the only difference I can see? gitlab_rails['gitlab_email_enabled'] = 'true'; gitlab_rails['gitlab_email_display_name'] = 'Gitlab'; gitlab_rails['gitlab_email_reply_to'] = '[email protected]'; gitlab_rails['smtp_enable'] = 'true'; gitlab_rails['smtp_user'] = '[email protected]'; gitlab_rails['smtp_address'] = 'mail.domain.net.au'; gitlab_rails['smtp_port'] = '25'; gitlab_rails['smtp_domain'] = 'domain.net.au'; gitlab_rails['smtp_authentication'] = 'false'; gitlab_rails['smtp_enable_starttls_auto'] = 'false';
  20. I've wondered the same and also had issues when using the --memory flag. It's suppose to run just fine on a RPI2/3 with 1GB of RAM (non-docker) using the Omnibus package but I guess there's additional config built into it. I started to play around with it but ran out of time. Google around and check the documentation, there's options to limit worker processes etc and this is what I was starting off with: postgresql['shared_buffers'] = '256MB'; unicorn['worker_processes'] = '3'; unicorn['worker_timeout'] = '60'; Can't remember how well it worked, other life things have gotten priority lately. Let me know how you go
  21. I had a similar issue. Here's how I fixed it: 1. SSH to Unraid 2. Start the docker and run 'docker ps' to get the container ID before it crashes again 3. Keep the SSH window open and get ready to do this as quick as possible a) Start the docker again either from cli or WebGUI b) Replace the 'DockerID' text below with the container ID you got from step 1 and run the following lines in the SSH windo docker exec -it DockerID chmod -R 0770 /var/opt/gitlab/git-data docker exec -it DockerID chmod -R 2770 /var/opt/gitlab/git-data/repositories c) If the docker crashes again, try restarting it again and everything was fine for me after that
  22. No idea on this one specifically. I run the CA nightly backup plugin and keep 30 days worth for the reason of auto or manual updates breaking the docker and loosing files
  23. Thanks to thomast_88 for setting up this docker I've set it up and muddled through learning git at the same time and just wanted to post a config I've came up with to let you use the "Linuxserver.io - letsencrypt" docker to reverse proxy the this (gitlab-ce) docker without having to use SSH etc to edit the gitlab.rb config file or any other suggestion I've seen here that involves a workaround of sorts like Gizmotoy's port workaround (although it did work). ##### How to use reverse proxy gitlab-ce with the letsencrypt docker Summary: I use the letsencrypt docker to reverse proxy my home stuff with each service being on it's own host.domain.com:443. I couldn't/didn't want to: NAT 80/443 or custom ports to this docker's built in nginx server so I could use it externally Not mess around with custom editing the standard docker config files I wanted all my URL's in gitlab-ce to show the proper https://host.domain.com/blah.git URL that I could just copy and paste them * These steps assume you have a NAT for letsencrypt:nginx set up correctly to reverse proxy on HTTPS/443. Don't ask for help here regarding getting that set up, please ask in the thread for that docker here Steps 1. Stop the docker 2. Reset your gitlab.rb file to docker/factory defaults 3. Add/Update your letsencrypt ngix config file area for gitlab-ce to use the following config and restart it. proxy_pass http://your.unraid.ip.here:9080; proxy_set_header X-Forwarded-Proto https; proxy_set_header X-Forwarded-Ssl on; 4. Edit the gitlab-ce docker, open advanced settings 5. Edit the 'Extra Parameters:' section and paste in the following; --env GITLAB_OMNIBUS_CONFIG="external_url 'https://host.domain.com/'; nginx['listen_port'] = 9080; nginx['listen_https'] = false" This is the standard config line included in the docker where your supposed to change the DNS name only. The line above changes http:// to https:// and passes config to the dockers built in nginx server to listen for https:// but not enable it's own SSL port and config. Reference: Supporting Proxied SSL https://docs.gitlab.com/omnibus/settings/nginx.html#supporting-proxied-ssl The reference link mention's about including a few more config items I already have them in the default letsencrypt nginx config so I didn't need to add them