svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-20 at 23:24:11+02:00
Argh, medzitym som stihol stratit antyho review napisany ako odpoved na commit mail. Ignorujte vyssie napisane :-)
Closed svtimport closed 9 years ago
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-20 at 23:24:11+02:00
Argh, medzitym som stihol stratit antyho review napisany ako odpoved na commit mail. Ignorujte vyssie napisane :-)
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-21 at 00:44:05+02:00
\- init_all.sh zavola aj make_config.sh ktory vyrobi defaultne config.yml a
parameters.ini ak este neexistuju.
\- app/cache, app/logs a db sa vyrobia ak neexistuju.Prave mazanie cache je vec, ktoru som robil kvoli opravneniam rucne.
Na produkcnej masine nechces mat na cache a log dir prava 777.
Chceme vobec niekedy mazat logy??
Argh, tie permissions su problem. Nad tym sa este musim zamysliet. (Ciel je skript co funguje na produkcnej masine, na devel masine so systemwide apachom, na devel masine s userwide lighttpdom, aj na svt-devel oneclick deploymente ked raz bude.)
Logy nie su skoro nikde. V anketa-dev je dev.log obsahujuci zaznam o kazdom jednom SQL dotaze (teda... kazdom dotaze vo fixtures), ale ostatne app/logs su uplne prazdne. Takze ked tak mame opacny problem :-)
\- farebne odliseny vystup od skriptov a vystup od nimi volanych programov.
\- restart_db.sh uz neni templatovany, premenoval sa na reset_db.sh a treba
ho
explicitne povolit v parameters.ini.Este by to chcelo, aby sa ta to spytalo, ci chces naozaj resetovat DB
(pre istotu).
Som mieeerne proti... mam pocit ze vo vacsine casov chces restartovat DB, a to aj pocas testovania - vtedy init_all davas casto a nechces furt davat navyse "y<enter>". Aj pripadny omyl prezijes, lebo to je z fixtures alebo z kopie ostrej alebo dacoho. Jediny pripad, ked DB mazat nechces, je, ked v DB mas vzazne data, to jest na produkcnej masine alebo vo vynimocnych testovacich pripadoch. A na to je potom ten riadok v parameters.ini. A je to opt-in, takze na starych parameters.ini to mazat nebude. (Ale v novom parameters.ini.template to uz je.)
\- z parameters.ini sa odstranil duplikatny secret.
Hmm, na co sa pouzivaju dva secret, je to bezpecne ked je tam len jeden?
Alebo sa jeden z nich nepouzival?
Volakedy sa pouzivali dva, teraz uz len jeden. V configu bolo iba "secret: csrf_secret" a secret nikde nebolo. Tak som to skonzistentnil na "secret: secret" a csrf_secret som z parameters.ini vyhodil.
svtimport
commented
12 years ago Updated by Martin Sucha on 2011-10-21 at 11:28:23+02:00
Tomáš Belan wrote:
\- init_all.sh zavola aj make_config.sh ktory vyrobi defaultne config.yml a
parameters.ini ak este neexistuju.
\- app/cache, app/logs a db sa vyrobia ak neexistuju.Prave mazanie cache je vec, ktoru som robil kvoli opravneniam rucne.
Na produkcnej masine nechces mat na cache a log dir prava 777.
Chceme vobec niekedy mazat logy??Argh, tie permissions su problem. Nad tym sa este musim zamysliet. (Ciel je skript co funguje na produkcnej masine, na devel masine so systemwide apachom, na devel masine s userwide lighttpdom, aj na svt-devel oneclick deploymente ked raz bude.)
Ja by som povedal, ze staci spravit konvenciu, ze ten skript budes pustat vzdy ako ten isty user ako bezi web server a malo by to byt vyriesene, nie?
Logy nie su skoro nikde. V anketa-dev je dev.log obsahujuci zaznam o kazdom jednom SQL dotaze (teda... kazdom dotaze vo fixtures), ale ostatne app/logs su uplne prazdne. Takze ked tak mame opacny problem :-)
Hmm. Alebo tam len nie je zapnute zapisovanie logov.
\- farebne odliseny vystup od skriptov a vystup od nimi volanych programov.
\- restart_db.sh uz neni templatovany, premenoval sa na reset_db.sh a treba
ho
explicitne povolit v parameters.ini.Este by to chcelo, aby sa ta to spytalo, ci chces naozaj resetovat DB
(pre istotu).Som mieeerne proti... mam pocit ze vo vacsine casov chces restartovat DB, a to aj pocas testovania - vtedy init_all davas casto a nechces furt davat navyse "y<enter>". Aj pripadny omyl prezijes, lebo to je z fixtures alebo z kopie ostrej alebo dacoho. Jediny pripad, ked DB mazat nechces, je, ked v DB mas vzazne data, to jest na produkcnej masine alebo vo vynimocnych testovacich pripadoch. A na to je potom ten riadok v parameters.ini. A je to opt-in, takze na starych parameters.ini to mazat nebude. (Ale v novom parameters.ini.template to uz je.)
OK, znies dost presvedcivo. Jedno mozne riesenie je pridat nejaky parameter tomu skriptu (i.e. --dont-ask), ktory nevadi ak ten skript pustat z bash historie. Dalsie co ma napada je, ze ten skript vzdy spravi backup databazy (co vsak asi pri vyvoji nie je uplne to co chces).
Co ty na to?
\- z parameters.ini sa odstranil duplikatny secret.
Hmm, na co sa pouzivaju dva secret, je to bezpecne ked je tam len jeden?
Alebo sa jeden z nich nepouzival?Volakedy sa pouzivali dva, teraz uz len jeden. V configu bolo iba "secret: csrf_secret" a secret nikde nebolo. Tak som to skonzistentnil na "secret: secret" a csrf_secret som z parameters.ini vyhodil.
O.K.
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-21 at 15:12:33+02:00
Je minimalne jedna akcia co musis spravit ako www-data (mazanie veci vnutri app/cache) a minimalne jedna co nemozes spravit ako www-data (vyroba adresara app/cache ak este neexistuje, lebo na to musis mat writeaccess ku app a ten je 755 anketa:anketa). Takze tam predsalen potrebujeme nejake sudo. Len to treba spravit rozumne tak, aby to fungovalo vo vsetkych pripadoch co nastavaju (vratane toho ze webserver bezi pod tvojim userom, co je napriklad na mojej devel masine), a o kazdom prikaze si premysliet ci ma bezat ako anketa (resp developerov ucet) alebo ako webserverov ucet.
--dont-ask nie. Ked tak "yes | init_all". yes je unixova utilita ktora donekonecna vypisuje "y" ;-)
Z vyssie opisanych dovodov je podla mna v 90% pripadoch uzitocnym defaultom reset databazy. Takze podla mna chceme riesenie, v ktorom povedat ze "ano chcem reset" ta stoji menej usilia, ale zaroven na strojoch kde resetovat nikdy nechces, fakt neresetujes. A to nam ten momentalny patch dava.
svtimport
commented
12 years ago Updated by Martin Sucha on 2011-10-22 at 11:24:48+02:00
Na druhu stranu ma napada, ze mazat cache na vyvojarskych masinach nemusis, pretoze je v dev environmente vypnuta. Cize by sme to imo mohli kludne oddelit (na produkcnej chces zase iba mazat cache).
Logy mazat netreba, kedze tam aj tak momentalne nic nie je.
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-26 at 16:10:19+02:00
Cache: aj v dev tam je vselico, napriklad skompilovane templaty. Ked nemazes cache tak to blbne.
Logy: ok, nebudu sa mazat, aj ked samozrejme priamo spustit clear_logs stale funguje.
Permissions: takto vyzera moj momentalny navrh, spravim to ked mi niekto odklepne design:
Momentalne mame jeden hlavny "entry point" skript, init_all.sh, co spravi vsetko potrebne. Myslim ze by to chcelo taketo skripty dva. Jeden, povedzme init_all.sh, ktory zavolas jediny raz po checkoute a stara sa o vyrobenie vsetkych potrebnych adresarov a konfigurakov. Druhy, reset_all.sh, robi viacmenej to co init_all.sh doteraz, cize resetne databazu, cache, logy^H^H^H^H atd.
Vsimnime si ze kedze install_assets.sh moze pouzivat symlinky (na windowse jednak mame install_assets.bat, druhak NT a vyssie uz maju symlinky builtin) tak instalujeme assets v init_all a nie reset_all. Tym padom zmena v js a css nevyzaduje reset_all.
Moze byt?
svtimport
commented
12 years ago Updated by Martin Sucha on 2011-10-26 at 21:07:15+02:00
OK. Vyzera, ze tato vec asi nebude moct byt uplne rovnaka na deploynutej masine a pri testovani - jednoducho tam su trocha ine poziadavky. Navyse sa mi nepaci na produkcnej masine davat sudo dovnutra skriptov - proste chcem vzdy vediet pod akym userom to bezi, to vsak neznamena, ze to nemozme pouzit na dev masine.
Navrhujem preto pouzite prefixu: premenovat init_all.sh na dev_init_all.sh (ten by mohol pustit aj ten update submodule), bol by to v podstate skript, ktory spustis po checkoutnuti repozitara a mohol by aj skontrolovat ci mas v PHP vsetky potrebne dependencies.
Potom dev_reset_all.sh by bol skript, ktory by robil to, co si popisal, ten by sa iba premenoval.
(zaroven by ten prefix dev_ znamenal, ze dane skripty sa nemaju pustat na prod masine).
Potom by update na prod masine mohol vyzerat ako sudo -u user1 prod_update.sh && sudo -u user2 prod_clear_cache.sh
Mohli by sme sa dohodnut takto?
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-27 at 12:21:39+02:00
Dalsia verzia.
OK, akceptujem tvoju podmienku ze "vnutri scripts sa nesmie pouzivat sudo" a este pridavam svoju podmienku ze "vnutri scripts sa nesmie pouzivat git". To preto ze sa mi nepacilo ani ked sa vsade pouzivalo svn (a bolo to treba vsetko prerabat).
Rozdelenie dev a prod skriptov neni dobry napad, lebo to neni to prave. Aj dev masiny su rozne - su take kde je jediny user (u mna je vsetko tomi:users) a take kde je aj devel user aj apache user, ktore vyzeraju (co sa pravomoci tyka) rovnako ako produkcna masina. (Ale od produkcnej masiny sa lisia obsahom configov a tym ze produkcna neresetuje db.)
init_all by sa nemal volat dev_init_all, lebo init_all sa pouziva pri inicializacii lubovolneho stroja, aj produkcneho (povedzme na inej fakulte) aj ineho. Vzdy chces pri inicializacii instalovat assety, vygenerovat secret do parameters.ini, a dalsie tieto veci. Ale budu v nom kontroly nech nic nespravi ak sa zavola na uz inicializovanej instancii.
Ked robis dev checkout, tak spravis toto:
git clone (adresa) fmfi-anketa
cd fmfi-anketa
git submodule update --init
./scripts/init_all.sh
\- defaultny config.yml inicializovany
\- defaultny parameters.ini inicializovany so sqlite databazou
\- assety nasymlinkovane
este musis spravit toto:
1. ak chces cosign a/alebo libfajr, nastav to v config.yml.
2. ak chces mysql namiesto sqlite, nastav to v parameters.ini.
3. vyrob adresare ./db, ./app/cache a ./app/logs s pravami 700 a vlastnene webserverom.
napriklad takto: sudo install -o www-data -g www-data -m700 -d ./db ./app/cache ./app/logs
4. spusti reset_all.sh pod userom webservera. (to vyrobi novu databazu.)
napriklad takto: sudo -u www-data ./scripts/reset_all.sh
5. ak bude tato databaza produkcna a uz nikdy ju nechces vymazavat, nastav to v parameters.ini.
init_all tym padom nepouziva git ani sudo, iba ti navrhuje ako to spravit. Hentie prikazy su presne to co treba na produkcnej masine (teda az na to ze tam init_all pustas pod userom anketa) a na webserverovej dev masine. Jedine na single-user dev masine je to kusok ine, a moze sa vyhodit vsetko sudo a optiony s www-data. Ale to je pomerne zistitelne ked clovek potrebuje.
(Ten 1. prikaz co init_all navrhuje sice vyzaduje roota, ale optimalizujem na bezny pripad. Ak roota nemas, tak si poradis - tie adresare sa daju vyrobit aj tak, len je to komplikovanejsie.)
reset_all imho moze zostat v tvare clear_cache;reset_db;clear_cache, v momentalnej verzii robi "spravnu vec" na kazdej masine. (To vdaka tomu ze reset_db kontroluje opt-in config.) Na produkcnej masine sice momentalny reset_all v konecnom dosledku robi iba clear_cache, ale mozno tam raz bude nieco dalsie, takze nechceme proste robit "prod_clear_cache", chceme furt davat reset_all.
Este v reset_all mozno bude nejaky prikaz alebo daco co overi ci sa spusta pod spravnym userom. Takze tam nebude priamo sudo ale ked ho pustis bez suda tak ti vynada.
Na produkcnej masine bude este k tomu skript /usr/local/bin/anketadeploy obsahujuci:
cd "${1:-/var/www/anketa-prod}" || exit 1
user=`stat -c %u ./scripts`
sudo -u "#$user" git pull
sudo -u "#$user" git submodule update
sudo -u www-data ./scripts/reset_all.shVdaka tomu sa vyhneme pouzivaniu sudo vnutri reset_all ale pritom je deployment stale na jeden prikaz.
Takze ako to cele vyzera z pohladu uzivatela (ktory tie skripty spusta):
Tato varianta by mala riesit vsetky vyssie spominane issues a pritom ma pomerne jednoduchy a pohodlny user guide.
svtimport
commented
12 years ago Updated by Martin Sucha on 2011-10-27 at 16:26:09+02:00
ok, myslim, ze moze byt tak ako si to popisal
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-27 at 18:42:48+02:00
Super. Ale este sa jedna zakernost skryva v implementacii, a to co sa tyka instalovania assetov.
Chceny vysledok: vo web/bundles/ sa objavia symlinky na jednotlive bundly, vlastnene samozrejme zdrojakovym userom. (Symlinky sice nemaju pravomoci ale maju vlastnika.)
install_assets.sh momentalne instaluje assety prikazom "php ./app/console assets:install ./web --symlink". Toto ma ten problem, ze ./app/console si vyzaduje pristup do app/cache a app/logs, a tie vlastni webserver s pravomocami 700. Takze zdrojakovy uzivatel sa k nim nedostane a app/console sa nespusti. Toto nie je specificke pre assets:install, app/console nevie pod zdrojakovym uzivatelom ani zobrazit help.
Moznost 1 (skareda): predsalen nepouzivat assets:install a vratit sa k hardcoded zoznamu assetov v skripte, ako bol v casoch svnka. Len s tym ze na rozdiel od svn nemusime blbnut s exportami a mozme spravit normalne symlinky.
Moznost 2 (skaredsia): pri instalovani assetov na chvilu niekam presunut app/cache a app/logs. (Na to zdrojakovy user nepotrebuje mat pristup k ich obsahu, staci write access do adresara app, a to ma.) app/console vyrobi svoju vlastnu cache a logs, a tu vzapati odstranime a dame tam tie stare.
Moznost 3 (pekna ale nefunkcna): assets:install normalne volame iba z init_all, este pred tym ako vzniknu app/cache a app/logs. (Lebo tie vzniknu ked ich uzivatel vyrobi po tom co mu init_all povie ako.) Mohli by sme sa spolahnut ze urcite app/cache a app/logs v tom case nebudu existovat, a nepodporovat instalovanie assetov po tom co uz vznikli. Lenze tym padom je po inicializacii prakticky nemozne tie assety menit.
Moznost 4 (asi najlepsia ale stale hack): ako moznost 1, ale zoznam bundlov neni hardcoded, ale ziskany prikazom "find -path '_/Resources/public'". Tym ziskas path bundlu, a meno bundlu zistis tak ze pohladas v $path/Resources/public/../.. subory '_Bundle.php'. Toto je v skutocnosti samozrejme hrozne nepresne, lebo realne pouzity zoznam bundlov je v PHP v app/AppKernel.php, ale ani doteraz nam to apparently nevadilo (web/bundles/webprofiler a web/bundles/symfonywebconfigurator sa maju vyrabat len v dev environmente). V symfony su hromady bundlov co ani nemame zapnute (v ziadnom environmente) ale nastastie tam momentalne nikde neni ziadne Resources/public.
Poznamka: windows teraz neriesim, tam by mal install_assets.bat normalne fungovat a s pravomocami by nemal byt ziaden problem.
svtimport
commented
12 years ago Updated by Martin Sucha on 2011-10-27 at 19:25:28+02:00
Hmmm.
Uz ma tie veci okolo permission na cache zacinaju stvat. Tusim to spravim tak, ako hovoril Ivan - t.j. bud web server bude mat umask 007 a grupu rovnaku ako cli, alebo to vsetko pobezi pod jednym userom.
1. toto by mohlo fungovat, len to treba rucne updatovat (co zas nie je tak casto), a neriesi to problem s ostatnymi symfony prikazmi
2. toto by tiez bolo schodne riesenie, len to ma taky isty problem ako to predtym
3. toto by naozaj nefungovalo
4. to je zase zbytocna duplikacia kodu
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-27 at 19:37:54+02:00
Neboj sa, koniec tunelu uz je na dohlad ;-)
(Ale for the record, co sa novych projektov tyka, symfony uz nikdy viac;)
Web server s grupou ako cli by asi isiel, ale ten setup je netrivialny. Spravit to na produkcnej masine by islo ale skomplikovalo by to instrukcie na vyrobu multiuser dev instancie. (A ta musi zostat jednoducha, lebo eventualne chceme aby bola dokonca "one click".) Takze tym by sme len problem presunuli inam. Na multiuser dev masinach to aj tak bude treba, tak to tak mozme nechat aj na prod masine.
Vsetko pod jednym userom tiez neni dobry napad.
1: ostatne symfony prikazy, co pouzivame, nemaju problemy. cely reset_db bezi pod webserver userom - mysql je OK, a sqlite je tiez OK lebo vlastnikom ./db je webserver. takze moznost 1 vyzera OK.
4: duplikacia kodu? nerozumiem. predstavujem si to cca takto:
IFS=$'\n'
mkdir -p web/bundles
for dir in `find -path '*/Resources/public'`; do
for bundle in "${dir%Resources/public}"/_Bundle.php; do
bundle=`tr A-Z a-z <<<"${bundle##_/}"`
ln -sf "../../$dir" "web/bundles/${bundle%bundle.php}"
done
done
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-28 at 02:10:11+02:00
Zase raz traktat textu ;-)
Alternativne riesenie (aj ked stale poprosim skomentovat aj komentar #12): pouzit posixove ACL.
Pomocou ACL vies vyrobit adresar app/cache (resp app/logs, resp db) a dat mu taketo pristupove pravidla:
Tym padom je jedno ci app/cache/foo.php vyrobil webserver alebo zdrojakovy user - obaja ho mozu citat, menit aj mazat. Nemusia sa o pristup do app/cache bit. (Vynimka: ten co povodne vyrobil nejaky subor, a teda je jeho ownerom, ma vyhodu v tom, ze moze jeho pravomoci zmenit a toho druheho "vymknut". Ale to sa v nasom pripade nema preco stat.)
Dosledky:
Cize zatial bezkonkurencne najlepsia varianta, len samozrejme s tou nevyhodou ze vyzaduje podporu ACL. Sme ochotni na tomto dependovat? Dalo by sa napriklad namietat ze setfacl je prilis nizkourovnovy, a podobne ako nechceme v skriptoch pouzivat sudo a git, nechceme ani setfacl. (Mne sa tam sice sudo a git nepacia ale setfacl mi pride OK.)
svtimport
commented
12 years ago Updated by Martin Sucha on 2011-10-28 at 18:13:48+02:00
Tomáš Belan wrote:
Neboj sa, koniec tunelu uz je na dohlad ;-)
(Ale for the record, co sa novych projektov tyka, symfony uz nikdy viac;)
OT (presunieme do mailov?): Preco nie? Myslis na nejaky iny framework? Ak ano, aky? Ak nie, preco?
Web server s grupou ako cli by asi isiel, ale ten setup je netrivialny. Spravit to na produkcnej masine by islo ale skomplikovalo by to instrukcie na vyrobu multiuser dev instancie. (A ta musi zostat jednoducha, lebo eventualne chceme aby bola dokonca "one click".) Takze tym by sme len problem presunuli inam. Na multiuser dev masinach to aj tak bude treba, tak to tak mozme nechat aj na prod masine.
Na druhu stranu je to jednoduchsie ako tie ACL-ka ;)
Vsetko pod jednym userom tiez neni dobry napad.
Preco? :)
1: ostatne symfony prikazy, co pouzivame, nemaju problemy. cely reset_db bezi pod webserver userom - mysql je OK, a sqlite je tiez OK lebo vlastnikom ./db je webserver. takze moznost 1 vyzera OK.
OK, dajme trebars zatial toto, nech sa uz nekasleme so skriptami a robime to co treba, uz treba pohnut, casu je malo.
4: duplikacia kodu? nerozumiem. predstavujem si to cca takto:
[...]
OK, to by tiez mohlo fungovat. (len je to vlastne prekodeny assets:install z php do bashu)
svtimport
commented
12 years ago Updated by Martin Sucha on 2011-10-28 at 18:39:13+02:00
Tomáš Belan wrote:
Cize zatial bezkonkurencne najlepsia varianta, len samozrejme s tou nevyhodou ze vyzaduje podporu ACL. Sme ochotni na tomto dependovat? Dalo by sa napriklad namietat ze setfacl je prilis nizkourovnovy, a podobne ako nechceme v skriptoch pouzivat sudo a git, nechceme ani setfacl. (Mne sa tam sice sudo a git nepacia ale setfacl mi pride OK.)
Toto iste ide spravit pomocou grupy uplne jednoducho, tak naco to komplikovat cez setfacl?
Navyse to nebrani one-click deploymentu vyvojovych verzii (proste sa to nastavi na zaciatku a potom namiesto setfacl pouzijes chgroup ak bude treba...)
Myslim, ze to nemusime nejak komplikovat.
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-10-28 at 22:51:36+02:00
OT (presunieme do mailov?): Preco nie? Myslis na nejaky iny framework? Ak ano, aky? Ak nie, preco?
Ah, sorry, to netreba brat prilis vazne. Len, ostatne frameworky app/cache nemaju ;-) Nemam na mysli ziaden iny framework, a prave nechystame ziaden novy projekt, takze si mozem dovolit hadzat odvazne hlasky. Na druhu stranu... so symfony a spol (vratane symfony DI, twigu, atd) som nikdy nebol prilis spokojny - vid moje predchadzajuce komentare na tuto temu. Keby sa zacinal novy projekt, dobre by som zvazil aj alternativy. Viac ked tak na mailingliste.
Preco sa mi najviac pacia ACL:Myslim ze ziadne ine riesenie neponuka vsetky hentie vyhody. ACL mi nepridu vyrazne komplikovanejsie alebo horsie zdokumentovatelne ako ine riesenia. Jedina nevyhoda je ze system ich musi podporovat, ale to dnesne linuxy uz zvladaju vsetky.
vsetko pobezi pod jednym userom
Nepaci sa mi to, lebo napriklad lubovolna nezabezpecena aplikacia na tom serveri zrazu moze tvoju aplikaciu komplet vymazat.
web server bude mat umask 007 a grupu rovnaku ako cli
To nam mozno pomoze na anketa.fmph a svt-devel, ale dava to vacsi burden na noveho developera. (Tym slovom samozrejme neoznacujem len noveho clena svt ale povedzme aj skuseneho developera s novym notebookom.)
OK, dajme trebars zatial toto, nech sa uz nekasleme so skriptami a robime to co treba, uz treba pohnut, casu je malo.
Huh? Nemal som dojem ze by nieco dalsie dependovalo na skriptoch, ostatni mozu dalej robit. Ci sa mylim? Radsej by som toto spravil poriadne na prvy pokus, ako zase to o pol roka musiet prerabat.
(Ah, este ujasnim: uz mam nejake proof-of-concepty viacerych spominanych variant, necakam s kodenim na finalny navrh. Akonahle sa na nejakom navrhu dohodneme, mozem pushnut na testovanie a ked mi niekto da LGTM, hned mergujem.)
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-11-02 at 12:00:26+01:00
Nejako to tu utichlo...
Ukazuje sa ze ACL nejde, lebo: normalne sa subory vyrabaju ako 0666 resp. 0777 a umask zabezpeci, ze sa to spravne oseka. Lenze Symfony a SQLite vyrabaju svoje cache subory a svoje databazy ako hardcodnute 0644, umask neumask. To jednak znemoznuje ten iny navrh ze dat umask=002, a druhak to kazi aj ACLka. Totiz, standard pre ACL sa snazi nejako tie ACL pravidla mapovat na stare "chmod"-style prava. Pravidla tvaru "owner = volaco" namapuje na prve cislo (cize 6), pravidla "others = volaco" namapuje na tretie cislo (cize 4), a ostatne na druhe cislo (cize 4). Takze sice som mu nastavil ze "vsetkym novym suborom nastav aby zdrojakovy mal rwx a webserver mal rwx" ale vzapati Symfony spravi chmod, moje pravidla sa vyANDuju so "4" a z mojich pravidiel zostane len "zdrojakovy ma r-- a webserver ma r--". No super.
Nuz, neprijemne... Kebyze nie hentoho tak mi ACLka pridu ako fakt najlepsie, ale holt nepojde to. Takze na stole zostavaju moznosti 1 a 4. Asi pouzijem moznost 1, je to sice skaredo hardcoded ale je oproti 4 mensia sanca ze to spravi nieco necakane. Niekedy coskoro sa mozno ukaze commit na review.
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-11-02 at 15:37:46+01:00
Tak, na improve-scripts je nieco reviewnutelne. Tri, dva, jedna, mozte kritizovat. :-)
svtimport
commented
12 years ago Updated by Tomáš Belan on 2011-11-08 at 23:55:20+01:00
Pripominaci ping, tento issue caka na review uz 6 dni. Niekto to reviewnite ak mozte.
svtimport
commented
12 years ago Updated by Tomáš Belan on 2012-02-13 at 15:33:29+01:00
Feature #21 imported from https://svt-devel.fmph.uniba.sk/chiliproject/issues/21 Author: Tomáš Belan Assignee: Tomáš Belan Priority: Normal Start date: 10/20/2011
Na vetve improve-scripts su nejake vylepsenia na scripts, zvlast restart_db (nech nemusi byt templatovany lebo to je strasnost). Poprosim review.
Zvlast ma v reviewe zaujima:
- mozu byt tie zvyraznene riadky v outpute? [anty says: mozu.]
- co dalsie zo scripts mozme bezpecne vyhodit? (viacere skripty tam su povodne z fajru a v ankete neboli nikdy pouzite... ale chcem sa radsej najprv spytat.)
- skusil som vhodne pozmenit aj .bat subory - funguje to na windowse? (aj ked miestami ani tie stare verzie imho nemohli fungovat, tak neviem ci to niekto pouziva.)
Tato issue mala povodne mailinglistovy thread "Anketa prekopane skripty", zacaty 2011-09-30. Skopiroval som sem vsetko relevantne (zvysok threadu sa tykal inych problemov). Na toto mi stale treba LGTM aby som mohol mergnut.
Created by Tomáš Belan on 2011-10-20 at 21:13:57+02:00