RAINBOF:pokud pouzivas hlavne ty, tak co udelat zaznam v .ssh/config


host mujgit
hostname githost
port 222

a ten ssh port docker gitu normalne vystavit na githost@222

pak veskery ssh konekce na mujgit pujdou na port 222

RAINBOF: Ja jsem to vzdal a nainstaloval gitlab z RPM misto dockeru. Ale az to vymyslis tak se podel o reseni.

THEODORT: tak hostnames mame. gitlab ma svy...

a nginx jao proxy ;-)

RAINBOF: je to velký zvíře no, nestačí ti třeba gitea? Teďka to má už i ekvivalent github actions :)

RAINBOF: mělo by jít udělat na hostovi uživatele git a tomu dát do authorized keys command ssh dockergit.

THERIDANE: jinej port beru jako plan b
(zatim se mi gitlab nepovedlo presvedcit k tomu aby to fungovalo dobre zda se ze ne na to neni uplne pripraven)

RAINBOF: Nejjednodušší je nastavit pro gitlab jinej SSH port. Pro uživatele je to transparentní, dostane remote URL ve správným formátu když si ji z webu zkopíruje, atd.

Ale jde to i jak píšeš pomocí ssh proxy, která de facto dělá mirror uživatele git@host a git@container. Ale je to hodně práce navíc :)

RAINBOF: presmerovat a obslouzit jinym ssh serverem...

Mam gitlab v dockeru, gitlab by se rad vystavil na portu 22 kde ale samozrejme mam ssh hostitele coz bych tak rad nechal. Je nejak mozny uzivatele git@ presmerovat jinym ssh serverem ?

Někdy se na potíže s bootem hodí REFind nebo v grubu:
linux (hd0/sd1)/boot/vmlinux- root=/dev/sda1
initrd (hd0/sd1)/biit/initrd
boot
...
ty prikazy jsou orientacni a boj s volume jsem vzdal
ve prospech prostych diskovych oddilu.
Hodne, v grubu, pomaha klavesa tabulator

ZBYNEK: Není tomu tak, ostatně viz screenshot. Při bootu se pomocí systemd generátoru vygenerují z fstabu patřičné služby a ta, která odpovídá tomu efi mountu se nenastartuje. Ve výchozí konfiguraci to ovšem zabrání úspěšné aktivaci local-fs.target a to zastaví celý boot. Vše je vidět v logu.

KARIBIKCZ: Což nemá žádný vliv na bootování, jenom systém nebude moct při updatech aktualizovat grub

RATTKIN: předpokládám, že `/boot/efi` se ze starého disku neklonovalo, tudíž ten nový /dev/nvme1n1p1 má jiné UUID než starý /dev/nvme0n1p1. Je tedy potřeba provést aktualizaci /etc/fstab (konkrétně opravit řádek pro mount /boot/efi)

RATTKIN: minimálně si stěžuje na disk 7149 8FFC a na /boot/efi, což by pro ten boot mohlo mít nějaký význam ...