Dod man \ "Obamas dolārus! \"

Mana uzņēmuma tīmekļa serveris atrodas koplietošanā, kas nozīmē, ka mums nav SSH piekļuves.

Es vēlos izmantot GIT mūsu versiju kontrolei, bet bez SSH piekļuves es domāju, vai ir pieņemami izvietot savas vietnes, izmantojot FTP. Vai es kaut ko zaudēju, izmantojot šo pieeju?

Kādas varētu būt galvenās kļūmes FTP, nevis SSH izmantošanā, ja kāds?

Tā kā mēs esam salīdzinoši maza tīmekļa konsultāciju aģentūra, vai būtu vērts tērēt papildu naudu veltītajam serverim?


Tas ir tas, ko es iedomājos par kļūmēm:

  • Failu pārvaldība ir mazāk efektīva
    • Papildu pūles, lai augšupielādētu tikai mainītos failus
    • Push / pull / clone funkcionalitātes zaudēšana serverī
  • Trivializē attālās centrālās repozitorijas izveidi (t.i., Github vai BitBucket)
    • Failu pārvaldība vienmēr notiks no lokālā uz serveri ...
    • ... nekad no centrālā repozitorija uz serveri vai otrādi

  • 4 Tas nav galvenais jautājums, taču koplietošana nenozīmē, ka nav SSH piekļuves. Es faktiski nevaru atcerēties pēdējo kopīgo plānu, kuram man bija piekļuve, un tas parādīja šo situāciju. Tātad, ciktāl iespējams, pāriet uz citu mitināšanu, jūs ne vienmēr meklējat īpašu serveri, tikai resursdatoru, kas jums nodrošina lielāku piekļuvi.
  • Es nezinu, ko jūs maksājat par koplietošanu, bet VPS patiesībā nav tik dārgs.
  • Visi koplietošanas mitināšanas plāni, kurus pēdējā laikā esmu izskatījis, ļauj SSH. Tie piedāvā piekļuvi Plesk vai cPanel dažādiem ļoti nepieciešamajiem administratīvajiem rīkiem. Laiks jaunināšanai? Vai arī pārbaudīt, vai jūsu pašreizējam pakalpojumu sniedzējam ir cits piedāvājumu segments? Kad es pieminēju nepieciešamību pāriet citur SSH, mūsu mitināšanas pakalpojumu sniedzējs mūs pārcēla uz mazāku skaitīšanas sistēmu, kas viņiem ir paredzēta lielākas datplūsmas vietnēm ar nelielu cenu, salīdzinot ar sākotnējo plānu. Ne SSH bija tikai jāsamazina izmaksas, ko rada pats lietotāju nodarītas brūces.

Es zinu, ka tas nav tas, par ko jūs vaicājāt, bet man pilnībā jāpiekrīt Su komentāros: ja jūsu mitināšanas pakalpojumu sniedzējs nedod jums piekļuvi SSH, jums vajadzētu nopietni sāciet meklēt jaunu pakalpojumu sniedzēju.

Tas nav tik daudz par SSH trūkumu kā tādu, bet gan par to, ka jūsu pašreizējais pakalpojumu sniedzējs acīmredzot nedod jums to, kas mūsdienās tiek uzskatīts par ļoti pamata un standarta funkciju pat vislētākajām tīmekļa mitināšanas paketēm. Šāds trūkums SJO rada nopietnus jautājumus par viņu vispārējo kompetenci un / vai klientu apkalpošanas līmeni.

No pakalpojumu sniedzēja viedokļa SSH piekļuves iestatīšanai ir ierobežotas sākotnējās izmaksas (galvenokārt tas ir saistīts ar pakalpojuma drošības nodrošināšanu un viņu darbinieku mācīšanu to administrēt) un būtībā nulles ekspluatācijas izmaksas pārsniedz parastos tīmekļa mitināšanas pakalpojuma darbības izdevumus. Ja viņi nevēlas to darīt, vienīgie paskaidrojumi, par kuriem es domāju, ir šādi:

  • viņi joprojām dzīvo pagājušajā tūkstošgadē un domā, ka SSH ir kaut kas jauns, ko neviens īsti neizmanto,

  • viņi baidās no drošības problēmām, kas rodas, piešķirot lietotājiem čaulas piekļuvi, un viņiem trūkst zināšanu, kā nodrošināt lietotājiem drošu čaulas piekļuvi vai iestatīt piekļuvi SCP / SFTP bez piekļuve čaulai vai

  • viņi darīt atbalsta SSH, taču viņi cenšas jūs niķelēt un pielīmēt, iekasējot par to papildu maksu.

Pirmajos divos gadījumos es nopietni apsvērtu, ko tas nozīmē par uzņēmuma tehnisko un drošības kompetenci, jo īpaši tāpēc, ka pastāv lielākā daļa drošības problēmu, kas saistītas ar piekļuvi čaulai vienalga ja mitināšanas uzņēmums ļauj saviem klientiem vispār izmantot jebkāda veida servera puses skriptus (PHP, CGI, ASP, Rails utt.).

Kas attiecas uz trešo gadījumu, tā, protams, ir likumīga cenu noteikšanas stratēģija, pat ja tā man šķiet mazliet neētiska, gan tāpēc, ka tas būtībā ir veids, kā mākslīgi pazemināt bāzes cenu, iekasējot papildus par viņu pamatfunkcijām varēja nodrošina bez maksas par būtību bez maksas, kā arī tāpēc, ka funkcija, par kuru viņi papildus iekasē, ir pamata drošības funkcija. Tas ir mazliet līdzīgi kā pārdot patiešām lētu automašīnu un pēc tam papildus iekasēt drošības jostas.

Galu galā, protams, jūs esat atkarīgs no tā, vai vēlaties palikt pie pašreizējā mitināšanas uzņēmuma un vai nu maksāt papildus par SSH, vai arī tikt galā ar tā trūkumu. Tomēr es vēlētos norādīt, ka mūsdienās daudzi pakalpojumu sniedzēji darīt iekļaut pilnu SSH piekļuvi kā standartu pat zemas klases mitināšanas paketēs. Mans ieteikums būtu vismaz paskatīties apkārt un redzēt, kādas izvēles jums ir.

  • Es to sekundēju. Jebkuram pienācīgam dalītā mitināšanas pakalpojumu sniedzējam būtu SSH piekļuve, jo SFTP drošības apsvērumu dēļ mūsdienās ir diezgan standarta. Un es koplietoto mitināšanu izmantoju vismaz kopš 2001. gada un nekad neesmu sastapies ar koplietošanas mitināšanas pakalpojumu sniedzēju, kas nenodrošinātu SSH piekļuvi. Varbūt mazākie ļauj jums izmantot tikai vienu SSH / SFTP kontu, taču viņi visi to nodrošināja kā standarta funkciju. DreamHost maksā mazāk nekā 9 USD mēnesī, un tas ļauj jums izveidot neierobežotu SSH / SFTP kontu.
  • Tas ir ļoti interesanti. Es runāju tieši ar viņu atbalsta (hmm ... varbūt tas bija pārdošanas) ļaudīm, un viņi teica: "Paldies par jūsu pacietību, Džefa kungs. Nē, ssh nav iespējams izmantot kopīgotajā mitināšanā, un, ja tas tā ir obligāti jums būs jānoslēdz līgums ar speciālu serveri "Tātad, jā ... es iegremdēšos nedaudz dziļāk un redzēšu, vai tas nebija tikai daži pārdošanas BS.
  • Jā, atbalsts apstiprina, ka nav SSH piekļuves. Tāpēc izvairieties no iWeb.com, ja vēlaties SSH un koplietojamo mitināšanu: \

Pār ftp tas zaudē punktu. Mans ierosinājums: saglabājiet savus projektus git'ed un, kad jums tas ir jāaugšupielādē koplietotajā mitināšanā, nelieciet git failus.

strādāja par jums: Charles Robertson | Vēlies ar mums sazināties?