Hiába keresgéltem és szűrtem a találatokat a DHU Fórum felületén, nem találtam igazan olyan általános kérdés+választ ami támpontot tudott volna nyújtani arra vonatkozóan, hogy miképp lehet hatékonyan és biztonságos módon a Drush-t használni a távoli szervereken.
A Level Ten Design publikált egy rövid filmet arról, hogy mennyire egyszerűen és könnyen lehet távoli tárhelyen is Drupal-t telepíteni parancssori környezetben. Szuper volt látni, hogy gyakorlatilag nem sok különbség van a lokális és távoli szervereken a Drush használata és elérése között.
A tapasztaltabb Drupal fejlesztők és SysAdminok számára valszeg eléggé rookie a kérdés amit hozzátok idézek, ezért megköszönném azt a pár választ, amivel útba igazítanátok a téma kapcsán.
Mire szeretném használni a Drush-t a bérelt szerveren lévő tárhelyen? Elsősorban olyan munkafolyamatok használatában, amely megkönnyíti azt és gyorsabbá teszi a Drupal weblapok adminisztrációját.
- Core parancsok használatára (install, update, backup, cron, cc stb)
- Aztán a Project Manager parancsok kiadására
- Szigorúan csak a lokális környezetben szándékozok majd a fejlesztéseket segítő egyéb Drush parancsokat használni. Pl. Userek vagy egy-két modul irányítására (Devel Generate, stb.)
Milyen környezetben kerülne bevetésre a Drush?
- Bérelt tárhely és nem különálló szerver
- Osztott tárhelyről van szó, ahol több weblap fut (mintegy egy tucat Drupal és hagyományos weblap)
- A szolgáltató biztosítja az SSH és a MySQL+SSH, Cron hozzáférést
- Apróbb fájlműveleteket már eddig is végeztem az SSH-n keresztül
- A .htaccess .bash_profile szerkesztés és parancsok futtatása is megengedett a hozzáérő számára
- Megbízható, hozzáértő és 365/7/24 elérhető a tárhely szolgáltató
Mit tanácsoltok, ilyen feltételek között hogyan lehet biztonságosan és optimálisan Drush-t használni?
Javasoljátok, hogy a tárhely gyökerébe telepítsem a Drush-t a weblapok mappáján kívülre, hasonlóan, ahogy a lokális szerveren lévő Site mappába, ahol az összes Drupal és nem Drupal weblap fut? Biztonsági szempontból ez nem jelent nagyobb kockázatot annál, hogy már most is osztott helyen és nem dedikált szervereken futnak a weblapok?
Nem kockázatos továbbá egy ilyen környezetben a .bash_profile szerkesztése, aliasok megadása, stb? Ti hogyan csinálnátok hasonló körülmények között?
Szeretném előbb demo Drupal weblapon használni a Drush-t a távoli szerveren és ehhez jöhetne a fenti témában egy-két jó tanács a részetekről, akár olyan is, ami még csak fel sem merült benne.
Remélem, hogy érthetően tudtam leírni, hogy miben kérem a segítségeteket a fórumon, amit előre is szeretnék megköszönni!
Szia!
Nagyon jó a videó.
"Javasoljátok, hogy a tárhely gyökerébe telepítsem a Drush-t a weblapok mappáján kívülre, hasonlóan, ahogy a lokális szerveren lévő Site mappába, ahol az összes Drupal és nem Drupal weblap fut?"
Igen, ahogy a videóban is volt.
"Biztonsági szempontból ez nem jelent nagyobb kockázatot annál, hogy már most is osztott helyen és nem dedikált szervereken futnak a weblapok?"
Szerintem jobb az átlagfelhasználónak, hogy a szolgáltató gondoskodik a biztonságról. Egy dedikált szerverhez rendszergazda is kell.
"Nem kockázatos továbbá egy ilyen környezetben a .bash_profile szerkesztése, aliasok megadása, stb? Ti hogyan csinálnátok hasonló körülmények között?"
Több tárhelyszolgáltató ad SSH elérést, plussz egy rakat parancssori parancsot, pl. a php is fut cli módban, ami a drush-nak szükséges (CLI-mode capable PHP binary version 5.3 or greater), van olyan szolgáltató, ahol még a drush is telepítve van, ha nem is a legfrissebb verzió.
Számomra ez azt jelenti, hogy ezek a szolgáltatók, a fenti SSH-s lehetőségekkel járó biztonsági kockázatokat tudják kezelni valahogy.
Köszönöm, akkor jó úton járok!
Köszönöm a válaszod, úgy néz ki, hogy akkor jó úton járok. Ma délelőtt sikeresen alámerültem a Drush használatába a távoli szerveren.
Demo Drupal weblapon telepítettem néhány modulnak a régebbi változatát, majd ezeket frissítettem. Az egyszerűbb műveletek már simán mennek. Szóval a Drush már rendben fut, a bash_profile-ban megadott aliasokat még nem sikerült rábírni erre, holnap konzultálok majd a szolgáltatóval. Ugyanez a helyzet újabb PATH változók megadásával. Addig is a hosszabb útvonalat megadva tudom futtatni a Drusht.
Nem gondoltam volna, hogy mint egy gyerek örülni fogok annak, hogy CLI-vel pikk-pakk el fogom tudni érni a weblapokat és frissíteni ezeket. Nagyon jó kis cucc ez a Drupal+Drush kombó, pedig én csak a felületét karcolom annak amire ez képes...
Még 1x köszi a jótanácsokat!