[ CoyoteKG @ 01.02.2019. 08:11 ] @
Može li hint :)

Kad kreiram neki user, ubacim ga u grupu www i chroot-ujem ga na /srv/www/ čiji je owner wwwrun:www, kako da prilikom uploada preko FileZilla, WinSCP ili tako nekog klijenta forsiram da svaki dokument koji uploaduje zadrži ownership parent foldera?
Odnosno da fajl nakon uploada nema ownership user:user, nego da ostane wwwrun:www, ili bar user:www?
[ CoyoteKG @ 01.02.2019. 10:02 ] @
OK, da ostane user:www, mogu da kad kreiram usera, kreiram da bude vec u grupi www
useradd -g www user

Mada sad razmisljam, mozda je i bolje da se vidi user:www na fajlovima koji su uploadovani od strane usera, ukoliko dodje do nekih problema sa malwerima, da se zna koji nalog je snimio fajl
[ nkrgovic @ 01.02.2019. 10:29 ] @
Ako hoces da ti default grupa za snimanje fajova bude X, stavi da mu je to primarna grupa. :)

Ako hoces da promenis, imas chgrp komandu, to i user moze da okine, za dve grupe, ako je u obe. To moze u skriptu za dizanje.

Ako te mucu privilegije, imas umask. Mozes da ga setujes i u profile za usera, a mozes i na klijentskoj strani.

Aman, zaman, NIKAD ne dizi kod na server preko WinSCP-a. Prvo, generalno, ne daj nikakvom idiotu da radi razvoj za unix/web na case insensitive fajl sistemu i sklepetaljkama tipa "WAMP", drugo i bitnije, kod se ne dize direktno na server kao user. Uradi deploy kao dedicated user, koji je vlasnik (znaci taj "www", ili napravi neki novi "web" samo za to), a programeri mogu da budu u grupi za situacije da u aman-zaman-slucaju-nuzde mogu da edituju direktno na serveru, ako bas mora.

Za dizanje koristi neki alat koji ce da povuce iz repo-a i spakuje na sajt. Ako nemas vremena ili resursa da pravis flow, imas alate tipa envoyer koji ti za sitne pare odrade te stvari. MORAS da imas opciju da uradi brz roll-back na prethodnu verziju koda, ako hoces da imas sistem koji radi... :)
[ CoyoteKG @ 01.02.2019. 10:54 ] @
Ovo pitanje nije vezano trenutno ni za test ni produkciju, nego generealno bas u tom slucaju, za eto "neku situaciju".
Recimo šta ako umesto WAMPa obezbedim dev server, a ne želim da dam root access tom serveru, nego da dozvolim useru osnovne komande poput git, zip/unzip, cp i slično...


Svakako da kad mi zatreba da ce ici kompletno CI/CD resenje.

Za sada znam da koristim AWS alate poput CodeDeploy i CodePipeline,
Pa mi je plan da prilikom merge na master branch, automatski se spuste fajlovi na produkciju. Pre toga na neki testni server. Jedino još nisam shvatio šta u slučaju da treba da se nešto i na bazi menja, osim da upucam skripte sa CodeDeploy "AfterInstall", ali sta onda za roll-back na prethodnu verziju što se tiče baze?... Jedino sa BeforeInstall dump baze kao backup koji bi se koristio za rollback...
[ nkrgovic @ 01.02.2019. 11:43 ] @
Citat:
CoyoteKG: Ovo pitanje nije vezano trenutno ni za test ni produkciju, nego generealno bas u tom slucaju, za eto "neku situaciju".
Recimo šta ako umesto WAMPa obezbedim dev server, a ne želim da dam root access tom serveru, nego da dozvolim useru osnovne komande poput git, zip/unzip, cp i slično...


Svakako da kad mi zatreba da ce ici kompletno CI/CD resenje.

Za sada znam da koristim AWS alate poput CodeDeploy i CodePipeline,
Pa mi je plan da prilikom merge na master branch, automatski se spuste fajlovi na produkciju. Pre toga na neki testni server. Jedino još nisam shvatio šta u slučaju da treba da se nešto i na bazi menja, osim da upucam skripte sa CodeDeploy "AfterInstall", ali sta onda za roll-back na prethodnu verziju što se tiče baze?... Jedino sa BeforeInstall dump baze kao backup koji bi se koristio za rollback...

Naravno, shell access za developere, posebno na test infra, ima smisla. Skroz OK, sve dok je tehnicki izvodljivo, za nuzdu bar. Tako da, nemam ja nista protiv, samo pojasnjavam (jer ovo je forum, a ne nas dvojica koji pricamo telefonom :) ) - da u produkcionom okruzenju mora da postoji deploy, a moze da postoji i ovo, za nuzdu. Problem je kad infra postane autoscaling, onda je to mnogo komplikovanije, ali, bar na testu, ovo je skoro uvek moguce i ima smisla. Zato ja volim OpenShift, na primer - mozes developeru da das shell i u kontejner, sto zna da bude zgodno kod debug-a.

Sto se tice rollback-a baze, to malo teze ide. Dump baze zvuci kao zanimljivo resenje, samo sto nije kad baza ima fazon 1TB. :) Onda ti dump+import traje ceo dan. U sustini, idealan odgovor je da se :

- Ako moze, pravi nedestruktivni change na bazi, pa onda ne mora roll back. Stvari tipa "alter table add column", ako je na kraj, ne bole. Dodavanje tabele ne boli. Brisanje slogova se ionako ne radi u normalnoj bazi.... Moguce je.
- Ako mora rollback, mozda moze neki green-blue pattern da se koristi, mada tu moze da bude problem ako ima izmena korisnicki generisane date. Mada to moze da se nadogradi, ali trazi vreme za implementaciju.
[ CoyoteKG @ 01.02.2019. 11:59 ] @
OpenShift je za sada daleko :D

A što se tiče rollback baze, nisam nešto stručan developerski, ali verujem da baš to... da ne bi trebalo da utiče na funkcionisanje aplikacije ako ostane neka kolona ili tabela viška. A i te kolone ili tabele ili štagod koje su se dodale pre tog deploy-a sa nekom skriptom, verovatno sa sličnom skriptom mogu i da se obrišu lako.

Kad pomenu... za deploy na autoscalling, da li je bolja praksa kreirati nov image ili startovati sve instance pa svuda uraditi deploy?


I ajd još jedno pitanje vezano za temu.

Ako hoću da chroot razlicite usere na razlicite foldere, kapiram da u sshd_config dodam ovako za razlicite usere

Match group sftp-users
ForceCommand internal-sftp
ChrootDirectory /srv/www


Match user blabla
ForceCommand internal-sftp
ChrootDirectory /srv/www/vhosts/test3.local


User blabla mi je u www grupi.
a www grupa je owner i rwx rekurzivno na /srv/www/vhosts/

ali kad pokušam sa blabla da se konektujem preko SFTP, dobijam error u logu
sshd[7699]: fatal: bad ownership or modes for chroot directory component "/srv/www/vhosts/"


ne verujem da je selinux, mislim da ga ovde na SLES i nemam po defaultu startovanog

[Ovu poruku je menjao CoyoteKG dana 01.02.2019. u 13:17 GMT+1]
[ CoyoteKG @ 01.02.2019. 13:21 ] @
OK, nasao sam problem sa chroot. Ne moze da bude 775 grupa nad chrooted folderom, mora 755.
pa mi je resenje u tom slucaju da unutar /srv/www/vhosts/test3.local kreiram public_html folder koji ce biti DocumentRoot za taj vhost sa 775 i grupom www
[ nkrgovic @ 01.02.2019. 13:27 ] @
Ja nesto radim, ali da bar ovo sto nisi resio:

Za baze, ako dodas kolone pazljivo, i ako je kod pisan kako treba, ne utice. Ako postoji replikacija situacija je slozenija ali izvodljiva, ako DBA zna sta radi. U svakom slucaju, na velikim tabelama alter table moze da traje satima, tako da nije bas kategorija koju bi opisao sa "moze da se obrise lako". Moze, ali nije lako.

Za autioscaling ne mozes da radis tako, moras da imas nov image, jer ako sredis i SVE instance, sve nove ce ti i dalje ici sa image-a. Alternativno, mozes da decouple-ujes kod od instance, kroz neki NFS, pa da ne moras da diras image.
[ CoyoteKG @ 01.02.2019. 13:33 ] @
da lupio sam najstrasnije za autoscalling :D

sve jasno, hvala