Fórum Root.cz
Hlavní témata => Server => Téma založeno: Tomas Lehocky 30. 11. 2018, 22:31:20
-
Ahojte
Z viacerých strán čítam že FTP pre prístup na server je
- zastarané
- nezabezpečené
- nebezpčné
...
Mám eshop. Máme testovaciu a produkčnú verziu. Server je na Linuxe. Programovanie zadávam viacerým externistom podla ich špecializacie.
Vždy keď niekomu zadávam robotu tak si ako prvé pýta FTP prístup na server. Všetci pracujú z Windows.
Aký protokol - službu mám zriadiť na serveri namiesto FTP.
Požiadavky:
- fungujúci wo Windows (buď natívne alebo cez nejakú aplikáciu)
- prehliadanie adresárovej štruktúry
- RW prístup
Ďakujem
-
FTP je nebezpecne, ptotoze prenasi heslo v plain textu. Proto se pouziva FTP over SSL
Nahradit ho muze pripadne pomoci SFTP - to je "soucast" sluzby SSH
Klient Filezilla
Pripadne muzete pouzit SCP, ktere take vychazi z SSH (program WinSCP)
-
sftp
-
Třeba by šlo prostě
https://en.wikipedia.org/wiki/FTPS
A zakázané spojení bez TLS, ideálně klidně ověřovat certifikát. Je to pořád old-school, ale bezpečné.
-
Buď SFTP nebo WebDAV. WebDAV je založený na HTTP, tedy je to stejná technologie, na které vám běží ten e-shop, takže se to někdy dá řešit jedním webovým serverem pro obojí.
-
Git s CI.
-
Git s CI.
Nj, konecne poriadna a koncepcna odpoved. Dajte si pol dna na to, aby ste si zistili ako funguje Git (idealne aj s CI), vacsina programatorov s nim uz (snad) robit vie a vyrazne vas to posunie dalej :)
-
Keďže to robí viacero programátorov, tak sa dá usudzovať, že potrebuješ aj versioning. Ale to musíš ty rozhodnúť, či áno alebo nie. Ak áno, tak je asi na to vhodný Git. Ale aj WebDAV umožňuje versioning. Ak nepotrebuješ versioning, tak je vhodné SFTP, ktoré im môžeš dať aj bez shell prístupu, alebo so shell prístupom obmedzeným na niekoľko príkazov. Windows 10 má linuxový shell. A ak nepotrebujú shell, tak sa tam dostanú aj cez Windows File Manager. Predpokladám, že okrem SMB podporuje aj SFTP, WebDAV a ďalšie protokoly. Ale neviem, nepoužívam Windows.
https://www.root.cz/clanky/jak-nahradit-ftp-pomoci-sftp-a-zamknout-uzivatele/ (https://www.root.cz/clanky/jak-nahradit-ftp-pomoci-sftp-a-zamknout-uzivatele/)
https://www.digitalocean.com/community/tutorials/how-to-enable-sftp-without-shell-access-on-ubuntu-16-04 (https://www.digitalocean.com/community/tutorials/how-to-enable-sftp-without-shell-access-on-ubuntu-16-04)
-
Keďže to robí viacero programátorov, tak sa dá usudzovať, že potrebuješ aj versioning. Ale to musíš ty rozhodnúť, či áno alebo nie. Ak áno, tak je asi na to vhodný Git. Ale aj WebDAV umožňuje versioning. Ak nepotrebuješ versioning, tak je vhodné SFTP, ktoré im môžeš dať aj bez shell prístupu, alebo so shell prístupom obmedzeným na niekoľko príkazov. Windows 10 má linuxový shell. A ak nepotrebujú shell, tak sa tam dostanú aj cez Windows File Manager. Predpokladám, že okrem SMB podporuje aj SFTP, WebDAV a ďalšie protokoly. Ale neviem, nepoužívam Windows.
https://www.root.cz/clanky/jak-nahradit-ftp-pomoci-sftp-a-zamknout-uzivatele/ (https://www.root.cz/clanky/jak-nahradit-ftp-pomoci-sftp-a-zamknout-uzivatele/)
https://www.digitalocean.com/community/tutorials/how-to-enable-sftp-without-shell-access-on-ubuntu-16-04 (https://www.digitalocean.com/community/tutorials/how-to-enable-sftp-without-shell-access-on-ubuntu-16-04)
jako ze bude mit versioning nekde na webu? Git at ma klidne u sebe, ale na webu at ma jenom relevantni data.
-
Ja z tej otázky nerozumiem, kde sú tie súbory. Možno by bolo vhodné použiť Rsync. A to možno aj ako mirror. Myslím si, že Rsync nefunguje vo Windows File Explorer tým spôsobom, že by som len zadal rsync:// . Ale ak by som cez linux shell na Windows 10 spravil rsync mirror, tak by som snáď tie súbory videl vo File Manager. Lebo požiadavka znela, aby to bolo aj v grafickom programe. Nech sa vyjadrí niekto, kto má Windows. Rsync dokáže to, že sa prenesú len zmeny, nie celý súbor. Myslím si, že to je v tejto diskusii tiež relevantné. Neviem, ktoré protokoly majú túto vlastnosť, nemám až taký prehľad.
-
jako ze bude mit versioning nekde na webu? Git at ma klidne u sebe, ale na webu at ma jenom relevantni data.
Úložiště Gitu bývá v cloudu, jeho CI/CD se stará o prezentaci na webovém serveru, na kterém jsou už jen relevantní data.
-
navrhovat WebDAV jako nahratu za FTP muze jen takovy odborni jako ty
Jenom trollíte, nebo máte něco konkrétního, co WebDAV neumí řešit a FTP ano? Víte, on WebDAV přímo vznikl pro autory webů, dokonce to má i v názvu. Vznikl tedy přesně pro potřeby toho, co Tomas Lehocky řeší.
-
Víte, on WebDAV přímo vznikl pro autory webů, dokonce to má i v názvu. Vznikl tedy přesně pro potřeby toho, co Tomas Lehocky řeší.
Ano, to je velmi užitečné vědět. Prakticky to sice vůbec nefunguje a uživatelé budou ten křáp dennodenně proklínat, ale na to Jirsák namítne, že přece je to pro ně přímo dělané, tak ať radši drží hubu. Teda hlavně že jsme odstranili to fujky hrozně nebezpečné FTP, protože bysme museli přidat asi pět řádků do konfiguráku na vynucení TLS.
-
On uz umi webdav menit prava k souborum a adresarum?
-
On uz umi webdav menit prava k souborum a adresarum?
Tady se bavíme o publikování na webový server, takže pokud myslíte oprávnění v souborovém systému, tam musí mít webový server právo číst a zapisovat, což je zajištěné tím, že tam ty soubory vytváří právě ten webový server. Jinak WebDAV umí přenášet libovolné vlastnosti souborů a kolekcí, k tomu byl navržen, takže přes něj dokážete přenést práva pro jakýkoli systém – můžete si tam namapovat klasická unixová práva, unixová ACL, Windows ACL nebo cokoli jiného.
-
Git s CI.
To je len pre tych, co sucitia s GITom. Spravil som to raz, potom mi tam jeden dev nahraval cez GIT kazdy den jedno 1GB propagacne video. Stare videa mazal a myslel si, ze to staci.
Na zdrojaky je to inak perfektne.
-
On uz umi webdav menit prava k souborum a adresarum?
Tady se bavíme o publikování na webový server, takže pokud myslíte oprávnění v souborovém systému, tam musí mít webový server právo číst a zapisovat, což je zajištěné tím, že tam ty soubory vytváří právě ten webový server. Jinak WebDAV umí přenášet libovolné vlastnosti souborů a kolekcí, k tomu byl navržen, takže přes něj dokážete přenést práva pro jakýkoli systém – můžete si tam namapovat klasická unixová práva, unixová ACL, Windows ACL nebo cokoli jiného.
Nahrada za proste FTP je FTP over SSL, pripadne SFTP nebo SCP
Ale pokud chces, pouzivej si klidne WebDAV - i ostrim noze muzes utahnout sroubek, kladivkem zatlouct sroub
To je jak se bavit s volem o sobote, kdyz jde v patek na porazku :(
-
Z viacerých strán čítam že FTP pre prístup na server je
- zastarané
- nezabezpečené
- nebezpčné
ano. Kdokoliv s pristupem na sit mezi tvymi kontraktory a tvym webem muze odposlechnout heslo.
Aký protokol - službu mám zriadiť na serveri namiesto FTP.
Nepridavej novou sluzbu a jen nakonfi SSH.
* jsou pro to pluginy do IDE.
* stejně tam asi uz je
* uspokojiva bezpecnost
* budes resit min potencialnich der protoze diry v SSH bys musel resit i tak.
takže stačí nastavit správny opravneni a je to. Pokud chces omezit pristup, zakaz login a povol jen scp/rsync..
webdav
mhmm, to je protokol ktery je fajn, ale nikdy se poradne neprosadil. Sam nevim proc.
-
Nahrada za proste FTP je FTP over SSL, pripadne SFTP nebo SCP
Ono není vždy nutné nahrazovat něco špatného něčím méně špatným, někdy to také můžete nahradit něčím, co je pro daný účel přímo určené. Což je právě případ WebDAV a správy webu. Ano, je možné, že zrovna pro případ Tomase Lehockeho nebude WebDAV vhodný. Ale zavrhovat WebDAV jenom proto, že o něm nic nevíte, není zrovna rozumné.
Nevýhoda FTP i FTPS je, že na to potřebujete speciální server a speciální komunikační kanál (HTTP/S funguje všude, což se o FTP nebo SSH říct nedá – mně se to sice nelíbí, ale nic s tím neudělám) a musíte pak na serveru řešit oprávnění, protože FTP server obvykle běží pod jiným uživatelem, než webový server. Nevýhoda SFTP je hlavně v tom, že pod tím pořád máte to SSH a musíte omezovat přístup tak, aby uživatel nemohl napáchat nějaké škody. Uděláte ze vzdáleného uživatele lokálního, a pak se ho snažíte udržet co nejdál. A s právy je to úplně stejné, jako u FTP(S).
-
A ono je uplne nejlepsi nahradit neco funkcniho a spolehliveho necim jinym s diskutabilnimi vlastnostmi...
-
Hele Jirsáku, co myslíš, že je důvodem stavu, cituji:
Programovanie zadávam viacerým externistom ... Vždy keď niekomu zadávam robotu tak si ako prvé pýta FTP prístup na server.
A/ Všichni externisti jsou dementní
B/ FTP funguje a pro daný účel naprosto dostačuje
C/ Je to spiknutí zpátečnických živlů
Proč asi nikdo z těch externistů nevolá: Já chci WebDAV! Teď hned, to je nástroj pro tu práci přímo stvořený! Nebo - já chci Git, prostě ho musím mít, jinak na to kašlu! Nebo - já chci přístup do shellu a SSH, okamžitě a střelhbitě ihned!
::) ::) ::)
-
Hele Jirsáku, co myslíš, že je důvodem stavu, cituji:
Programovanie zadávam viacerým externistom ... Vždy keď niekomu zadávam robotu tak si ako prvé pýta FTP prístup na server.
A/ Všichni externisti jsou dementní
B/ FTP funguje a pro daný účel naprosto dostačuje
C/ Je to spiknutí zpátečnických živlů
Proč asi nikdo z těch externistů nevolá: Já chci WebDAV! Teď hned, to je nástroj pro tu práci přímo stvořený! Nebo - já chci Git, prostě ho musím mít, jinak na to kašlu! Nebo - já chci přístup do shellu a SSH, okamžitě a střelhbitě ihned!
::) ::) ::)
Funguje a pro daný účel naprosto dostačuje zakrývat se lopuchem, utírat se tímtéž a spát v hnízdě na stromě. Akorát jsme postupem doby zjistili, že se to dá dělat i lépe.
-
Jirsaku - nemas patent na moudrost a prestan uz konecne vnucovat svou pravdu vsem ostatnim
Diskutujes hodne, ale ve finale o nicem a uplne mimo puvodni tema "Náhrada za FTP - prístup programátorov na server"
-
Jirsaku - nemas patent na moudrost a prestan uz konecne vnucovat svou pravdu vsem ostatnim
Diskutujes hodne, ale ve finale o nicem a uplne mimo puvodni tema "Náhrada za FTP - prístup programátorov na server"
A jéje, mistr světa promluvil. Pardon, já sem nevěděl, že máte patent na rozum a jediný, kdo může napsat svůj názor, jste vy. To jsem si teda dovolil pěknou drzost, napsat něco, s čím nesouhlasíte.
-
Pis si co chces, ale hlavne neplacej nesmysly
Ale tebe psani vylozene bavi, tak to potom promin...
-
Pis si co chces, ale hlavne neplacej nesmysly
Ale tebe psani vylozene bavi, tak to potom promin...
Nesmysly tu (a nejen tady) píšete vy. Protokol WebDAV vznikl z toho důvodu, aby správce webu mohl na webovém serveru manipulovat se soubory, tedy přesně pro to, co potřebuje podle svého dotazu Tomas Lehocky. Je klidně možné, že pro něj WebDAV z nějakého důvodu nebude nejlepší řešení, ale jedno z možných řešení to rozhodně je. Nesmyslné jsou akorát vaše komentáře o tom, že se k tomu WebDAV použít nedá. Neuvedl jste žádný důvod, proč by to nešlo, akorát trollíte.
-
jedina spravna odpoved byla
git + CI
. ja ji jen doplnim: najmi si nekoho kdo ti tohle dokaze rozumne nasadit, dokaze ti nastavit prava na mergovani v gitu.
pak az ti nekdo napise, ze chce pristup na ftp tak mu odpovez: NEMAM. dej mi svuj login na github/gitlab/bitbucket (nepocitam s tim, ze bys chtel provozovat tohle na vlastnim serveru) a ja ti dam pristup k repo.
vsechny ostatni rady jsou na hovno stejne jako soucasny stav kdy nekdo kopiruje soubory na produkci pres FTP(a tim i evidentne neverzuje).
EDIT: a pokud nekdo chce pristup na FTP jako prvni vec tak od nej dej ruce pryc. je to nedouk, amater, prznič.
-
A musim verzovat i treba instalaci Wordpressu? I to musim davat na server pres GIT?
BTW - a upload fotek musim taku delat jen pres git? Jine cesty jsou spatne?
-
Ty lidi jsou fakt úplně vymaštěný... Verzovat si můžu u sebe při vývoji, na hostingu (webserveru) určitě nic verzovat nebudu a normálně to tam vrznu přes FTP, jako milionkrát předtím. A nejlepší si je narvat do gitu třeba videa a tak. A verzovat.
::) ::) ::)
-
A musim verzovat i treba instalaci Wordpressu? I to musim davat na server pres GIT?
BTW - a upload fotek musim taku delat jen pres git? Jine cesty jsou spatne?
- ano, i u wordpressu je dulezite verzovat.
- ne, nerikal jsem nasazovat pres git, nasazovat muze CI treba pres rsync (a navic jen nektere soubory - treba vynechanim lokalni konfigurace, vynechanim scss apod a naopak nejake prida buildem treba css)
- ne, fotky jsou uzivatelsky obsah, ten je samozrejme vyloucen pres .gitignore
-
normálně to tam vrznu přes FTP
v době kdy už browsery standardně varují uživatele před neSSL HTTP, je používání nezabezpečeného kanálu pro administraci dost mimo.
Jasný, jsou případy (server mám přímo v síti, mám VPN k poskytovateli webhostingu, atp.), kdy jde FTP u starých projektů ospravedlnit, ale OP takový případ nezmiňuje.
Myslím, že by nikoho nenapadlo zadávat přihlášení do banky přes plaintext http. Existují (i webové) projekty, které mají řádově vyšší cenu než je zůstatek na onom bankovním účtu, kde by si nikdo nezabezpečené přihlášení nevrznul.
Jinak myslím, že FTP je jeden z posledních dožívajících protokolů z doby kdy Internet byla akademická síť..
-
FTP je jeden z posledních dožívajících protokolů
A o FTP over SSL jsi slysel?
-
FTP je jeden z posledních dožívajících protokolů
A o FTP over SSL jsi slysel?
Ne, a diskusi taky nečet. Ale zato si zahýkal, jak je to nebezpečné. Sice tady nešifrované FTP nikdo nenavrhoval, ale to je jedno, hlavně si zařvat.
-
FTP je jeden z posledních dožívajících protokolů
A o FTP over SSL jsi slysel?
Ne, a diskusi taky nečet. Ale zato si zahýkal, jak je to nebezpečné. Sice tady nešifrované FTP nikdo nenavrhoval, ale to je jedno, hlavně si zařvat.
Jeste tu chybi Jirsak, aby nam vysvetlil jak to vsechno delame spatne...
-
A musim verzovat i treba instalaci Wordpressu? I to musim davat na server pres GIT?
BTW - a upload fotek musim taku delat jen pres git? Jine cesty jsou spatne?
Sice nedělám web, ale řešení s GITem má několik výhod:
1) Přenos může být nativně po SSH - zabezpečeno, autorizováno
2) Příkaz git blame - kdykoliv se může podívat, kdy, kdo a co zprznil
3) Rychlý návrat k předchozí verzi při problému
4) Podpora submodulů - můžu si vložit aresář z jinýho repa, třeba CMS. Pokud má někdo WP v GITu, tak snad není problém.
Co se fotek týká, ty do GITu jako binárky nepatří. Ale to není problém, protože fotka je snad obsah webu, ne? Ten by se měl uploadovat standardně z browseru, když se přihlásí uživatel s daným právem. A upload fotky zásadně NESMÍ měnit práva k souborům - všechny fotky mají mít stejnýho vlastníka a stejný práva. Možnost to měnit smrdí zranitelností webu (eskalace práv).
Deploy z GITu dělat jenom na CMS/moduly/styly atd. Fotky/videa mají být v extra adresáři s korektně nastaveným přístupem a indexovaný v DB (to FTP neumí). Texty, popisy zboží, tabulka s cenama v e-shopu apod. se tam stejně lejou dynamicky přes DB.
-
Tak tys tady chybel...
ad 1/ FTP over SSL - v cem je to horsi/nebezpecnejsi nez SFTP/SCP_
ad 2/ git repo nema co na verejnejm web serveru delat
ad 3/ co treba rsync, FP upload? Ty nefunguji?
ad 4/ jak tohle nahradi poradek v datech a usnadni praci - nekomu mozna jo
Uplodovat stovky/tisice fotek pres HTTP formular s omezenim upload_max musi byt opravdu zazitek...
-
ad 2/ git repo nema co na verejnejm web serveru delat
ad 3/ co treba rsync, FP upload? Ty nefunguji?
Uplodovat stovky/tisice fotek pres HTTP formular s omezenim upload_max musi byt opravdu zazitek...
Nikdo tady přece nenavrhuje dávat Git repository na webserver. Něco jsem snad přehlédl?
Pokud nechceš fotky nahrávat přes HTTP, můžeš použít zmíněný WebDAV. Rsync je také dobrý. Ovšem dotaz byl na správu aplikace, nikoli na nahrávání dat. To je přece jen trochu rozdíl.
-
Já pro svých pár web serverů na linuxu používám pro správu, konfiguraci a download/upload souborů SSH/SCP.
Jako klienta pro vše uvedené jsem si ve Windows oblíbil volně dostupný Bitvise SSH Client (dříve Bitvise Tunellier).
-
Já pro svých pár web serverů na linuxu používám pro správu, konfiguraci a download/upload souborů SSH/SCP.
Jako klienta pro vše uvedené jsem si ve Windows oblíbil volně dostupný Bitvise SSH Client (dříve Bitvise Tunellier).
Tohle je v pořádku, pokud se o web stará jeden vývojář. Už u dvou však mohou nastat potíže.
-
ad 1/ FTP over SSL - v cem je to horsi/nebezpecnejsi nez SFTP/SCP_
V tom, že je to jenom nástavba. By default dovoluje autentizaci a pokud na serveru nedáš, že je povinná, následuje fallback na klasický FTP. Šifrování a ověřování integrity je další option, by default vypnutá a pokud útočník stopí příslušný příkaz (odpočítá potvrzení od serveru, například), tak payload valí nešifrovaně a bez ověřování. Viz https://tools.ietf.org/html/rfc2228, strana 9, první odstavec.
ad 2/ git repo nema co na verejnejm web serveru delat
To ovšem obecný protokol pro připojení jako filesystému taky ne. Pokud se někdo připojí filesystémem k webu, dostane možnost nahrávat, mazat, kopírovat a měnit soubory. Nejenom ty, co chceš, aby s nima pracoval. Takže na omhle levelu fakt jenom hrstka vyvolených a ne nájemná síla, na kterou nemáš páky.
Fakt je úplný nesmysl, že by konkurence podplatila jednoho kontraktora, aby jí vykopíroval jistý soubor s přihlášením k DB zákazníků, těm pak nabídla cílenou kampaní slevu, aby je přetáhl a ještě to nenápadně podstrčila na UOOÚ, aby ti zavařila ještě víc?
Jak ten přístup budeš auditovat?
Jak dokážeš v případě FTP u správního řízení/soudu, že se přihlásil skutečně on a ne někdo, kdo odposlech heslo? Řekne, že plaintext přihlašování jsi nasadil ty a byla to tvoje zodpovědnost a nevymluvíš se z toho.
ad 3/ co treba rsync, FP upload? Ty nefunguji?
To funguje výborně, dokonce na neveřejným test serveru můžeš mít hook, který při merge do produkční větve RSYNCne soubory automaticky. Vývoj pak jed proti test serveru a je zaznamenáno, kdo kdy co pustil. A souborem .gitignore se vyřeší i to, že některý soubory (aka klíče k HTTPS) v GITu nebudou (a tím nebudou ani k dispozici vývojářům). Ale musíš si hlídat pár věcí, který u FTP(S) neuhlídáš. Takže tak.
ad 4/ jak tohle nahradi poradek v datech a usnadni praci - nekomu mozna jo
Pořádek v datech? Ten snad má být v databázi, ne? Chtěl jsi asi říct pořádek ve zdrojácích...
Pořádek ve zdrojácích nezávisí na tom, jak je přesouváš, ale na tom, kdo se o ně stará.
Jak sdílení souborů rozliší mezi novou a starou verzí, jak zaeviduje změnu, jak zabrání v přístupu externisty k privátním klíčům?
Uplodovat stovky/tisice fotek pres HTTP formular s omezenim upload_max musi byt opravdu zazitek...
Počítám, že o těch fotkách musí vědět CMS. Co na nich je, kam je použít, jaký je popisek, copyright k tomu,... To tam stejně musíš nasázet ručně. Popřípadě pořešit škálování atd. Soubor se nahraje dřív, než vyplníš info o něm, úpravy a uložení metadat do DB zvládne appka na webu. Protože jinak bys tam musel stejně mít appku na webu, která po nahrávání fotek najde nový, vytáhne EXIF, škáluje, vyžádá si zařazení do galerií,... Nalít někam pár tisíc souborů s kontrolou a uložením informací o nich je totiž opruz vždycky.
-
ad 1/ FTP over SSL - v cem je to horsi/nebezpecnejsi nez SFTP/SCP_
V tom, že je to jenom nástavba. By default dovoluje autentizaci a pokud na serveru nedáš, že je povinná, následuje fallback na klasický FTP. ...
Když to, kokote, neumíš nastavit, tak nespravuj servery. Je to opravdu rocket science, viz např. u proftpd je vynucení TLS na celou jednu řádku.
TLSRequired off
U Pure-FTPD (https://download.pureftpd.org/pub/pure-ftpd/doc/README.TLS) to je jedna opravdu nesmírně složitá volba při spuštění:
--tls=3
cleartext sessions are refused and only TLS compatible clients are accepted.
Clear data connections are also refused, so private data connections are enforced.
Bože můj, tyhle spasitele opravdu na potkání střílet. RTFM (http://www.proftpd.org/docs/howto/TLS.html) a neraď, když jsi úplně vylízanej. Nástavbo.
-
Bože můj, tyhle spasitele opravdu na potkání střílet. RTFM (http://www.proftpd.org/docs/howto/TLS.html) a neraď, když jsi úplně vylízanej. Nástavbo.
Jsem rád, že se toho nakonec zhostil odborník (*) a osvětlil, jak to nakonfigurovat. Ono totiž tady zaznívalo jenom "FTPS je vždycky v pohodě" a žádný expert se nezalamoval s tím, jak debilně má podle RFC nastavený defaulty, že je potřeba server s možností jejich změny a ty změny vynutit.
I správně nakonfigurovaný FTPS ale dovoluje přístup k důvěrným read-only datům jako RSA klíče a dávat přístup k produkčnímu severu třetí straně je blbost zhruba na tvé úrovni.
A jenom pro info opakuju, že nedělám ani weby, ani se nestarám o servery. Takže tvoje přání rád splním, zvlášť když vidím, co se o ty stroje občas stará za případy (poslední expert od zákazníka, se kterým jsem se osobně bavil, se bojí pavouků a IPv6 a žije v představě, že nemůže mít oddělenou LAN, pokud za tou zásuvkou je v kanclu pod stolem switch). Nerad bych spadl na tvůj level.
Jenom používám Linux při práci a mám aspoň minimální představu o tom, jak kterej protokol chodí a v čem může být problém. Což se o řadě údržbářů říct nedá.
---------------------------
*) Odborník je ten, kdo už ve svým oboru udělal všechny možný průšvihy
-
dávat přístup k produkčnímu severu třetí straně je blbost zhruba na tvé úrovni.
A jak ma, prosim, treti strana spravovat data na produkcnim serveru?
nedělám ani weby, ani se nestarám o servery
To jsme uz pochopili - proto jsou ty rady tak odborne...
-
nedělám ani weby, ani se nestarám o servery
To jsme uz pochopili - proto jsou ty rady tak odborne...
;D ;D ;D
-
A jak ma, prosim, treti strana spravovat data na produkcnim serveru?
Tim, ze vytvori Pull request a ten je pak schvalen (projdou automatizovane testy, nekdo to otestuje manualne a pak to nekdo schvali) nacez CI nasadi program do produkcniho prostredi.
-
Ďakujem za vyčerpávajúcu diskusiu a podnety.
Nasadíme GIT. Aspoň vyriešime dve veci naraz - verzovanie aj bezpečnosť. Jeden externista to tiež odporúčal.
Podla informácii to vyzerá že by mala byť jasná voľba umiestniť Wordpress na Github/lab. (samozrejme bez obrázkov a zákazníckych dat. Ja mám však rád veci pod svojou strechou (prevádzkujeme vlastný firemný nextcloud ...).
Mám sa púšťať do spojazdnenia gitu + súvisiacich nástrojov na vlastnom serveri alebo je to fakt náročné a radšej zvoliť Github/älab?
-
Mám sa púšťať do spojazdnenia gitu + súvisiacich nástrojov na vlastnom serveri alebo je to fakt náročné a radšej zvoliť Github/älab?
Zprovoznění samotného Gitu je poměrně snadné, ale vyladit související nástroje do podoby GitHubu/GitLabu je už o dost obtížnější. Doporučil bych využití cloudu - je to už pro vývojáře nachystané a získáš tam dobré návyky.
-
Prestoze neni nikterak tezke rozjet gitlab na svem tak bych jednoznacne doporucil v tomhle pripade pouzit sluzby.
-
Upresnenie:
Mame testovací a produkčný eshop. Samozrejme na testovacom eshope niesú žiadne firemné ani zákaznícke dáta a externisti majú prístup na testovací server, kde prebieha vývoj.
Otestované a finálne moduly/súbory si na produkčný eshop nasadzujem sám. Prístup mám cez SSH a SSHFS. (SSHFS nikto nechcel)
-
Ok takže ten Github/lab.
Jedna vec mi ale stále nieje jasná.
Teraz to máme tak ze programator nieco spravi a nahraje to na testovaciu verziu eshopu. A tam ci hneď môže pozrieť ako to vyzerá na desktope, v mobile. alebo či sa to správa tak ako chcel.
Get to bude na externom gite ako budem na tetovací eshop nahrávať zmenené/nové súbory? (cez rsync - ten sa vie prihlásiť na github/lab?)
-
Ok takže ten Github/lab.
Jedna vec mi ale stále nieje jasná.
Teraz to máme tak ze programator nieco spravi a nahraje to na testovaciu verziu eshopu. A tam ci hneď môže pozrieť ako to vyzerá na desktope, v mobile. alebo či sa to správa tak ako chcel.
Get to bude na externom gite ako budem na tetovací eshop nahrávať zmenené/nové súbory? (cez rsync - ten sa vie prihlásiť na github/lab?)
U mna mam post-commit hook na svojom serveri. Ak mas nieco hostovane ako gitlab, tak ti hook moze spravit callback na testovaci server, ktory spravi checkout novej verzie.
-
navrhovat WebDAV jako nahratu za FTP muze jen takovy odborni jako ty
Jenom trollíte, nebo máte něco konkrétního, co WebDAV neumí řešit a FTP ano? Víte, on WebDAV přímo vznikl pro autory webů, dokonce to má i v názvu. Vznikl tedy přesně pro potřeby toho, co Tomas Lehocky řeší.
Zas blabolis jirsaku o vecech o kterych vis lautrhovno? Tahle sracka nikdy nefunovala a nikdy fungovat nebude a ani nemuze. To uz je lepsi napad si po netu pripojit sambu.
-
A jak ma, prosim, treti strana spravovat data na produkcnim serveru?
Tim, ze vytvori Pull request a ten je pak schvalen (projdou automatizovane testy, nekdo to otestuje manualne a pak to nekdo schvali) nacez CI nasadi program do produkcniho prostredi.
A to ma byt nahrada za proste FTP?
Taky odbornik?
-
Ok takže ten Github/lab.
Jedna vec mi ale stále nieje jasná.
Teraz to máme tak ze programator nieco spravi a nahraje to na testovaciu verziu eshopu. A tam ci hneď môže pozrieť ako to vyzerá na desktope, v mobile. alebo či sa to správa tak ako chcel.
Get to bude na externom gite ako budem na tetovací eshop nahrávať zmenené/nové súbory? (cez rsync - ten sa vie prihlásiť na github/lab?)
U mna mam post-commit hook na svojom serveri. Ak mas nieco hostovane ako gitlab, tak ti hook moze spravit callback na testovaci server, ktory spravi checkout novej verzie.
To jsme ten workflow ale zjednodušili, co? ;D ;D ;D