Hvordan du konfigurerer Dev Machine til å jobbe hvor som helst (del 3)

I tidligere artikler, jeg snakket om min mobil oppsett og hvordan jeg er i stand til å fortsette å arbeide på farten. I denne siste avdrag, vil jeg snakke om hvordan du installerer og konfigurerer programvaren jeg bruker. Det meste av det jeg snakker om her er på serversiden, fordi Android og iPhone apps er ganske grei å konfigurere.

Før vi begynner, men jeg vil nevne at dette oppsettet jeg har vært å beskrive egentlig ikke er for produksjonsmaskiner. Dette bør bare være begrenset til utviklings- og testmaskiner. Dessuten er det mange forskjellige måter å arbeide eksternt, og dette er bare en mulighet. Generelt, du virkelig ikke kan slå en god kommandolinjeverktøy og SSH-tilgang. Men i noen tilfeller, som ikke virkelig fungerer for meg. Jeg trengte mer; Jeg trengte en full Chrome Javascript debugger, og jeg trengte bedre tekstbehandling enn det som var tilgjengelig på min Android tabletter.

Her er da hvordan jeg stilt inn programvaren. Vær imidlertid oppmerksom på at jeg ikke skriver dette som en komplett tutorial, rett og slett fordi det ville ta for mye plass. I stedet, jeg gir oversikter, og forutsatt at du vet det grunnleggende og kan google for å finne detaljene. Vi vil ta dette steg for steg.

Spinn opp serveren din

Først spinner vi opp serveren på en vert. Det er flere hosting selskaper; Jeg har brukt Amazon Web Services, Rackspace og DigitalOcean. Min egen personlige preferanse for operativsystemet er Ubuntu Linux med LXDE. LXDE er en full skrivebordsmiljø som inkluderer OpenBox. Jeg personlig liker OpenBox på grunn av sin enkelhet og samtidig opprettholde visuell appell. Og LXDE er fint fordi, som navnet antyder (Lightweight X11 Desktop Environment), er det lett. Imidlertid vil mange forskjellige miljøer og vindusbehandlere fungere. (Jeg prøvde et par flislegging vindusbehandlere som i3, og de virket ganske bra også.)

Den vanlige rekkefølgen av installasjonen går som dette: Du bruker hosting selskapets hjemmeside for å spinne opp serveren, og du gir en viktig fil som skal brukes til å logge inn på serveren. Du kan vanligvis bruke din egen nøkkel som du genererer, eller ha tjenesten generere en nøkkel for deg, i hvilket tilfelle du laste ned nøkkelen og lagre det. Vanligvis når du gir en nøkkel, serveren vil automatisk bli konfigurert til å logge inn kun ved hjelp av SSH med nøkkelfilen. Men hvis ikke, vil du ønsker å følge deaktivere passord innlogginger.

Koble til serveren

Det neste trinnet er å faktisk logge inn på serveren via en SSH kommandolinjen og satte opp en bruker for deg selv som ikke er rot, og deretter sette opp skrivebordsmiljø. Du kan logge inn fra den stasjonære Linux, men hvis du liker, er dette en god mulighet til å prøve ut å logge inn fra en Android eller iOS tablett. Jeg bruker JuiceSSH; mange mennesker som ConnectBot. Og det finnes andre. Men avhengig av hva du får, sørg for at det tillater deg å logge inn med en nøkkel-fil. (Viktige filer kan lages med eller uten passord Pass også på programmet du bruker kan du bruke hvilken som helst tast filtype du opprettet -.. Passord eller ingen passord)

Kopier nøkkelfilen til nettbrettet . Den beste måten er å koble nettbrettet til datamaskinen, og overføre filen. Men hvis du ønsker en rask og enkel måte å gjøre det, kan du sende den. Men vær klar over at du sender den private nøkkelfilen via en e-post system som andre mennesker kan potensielt tilgang. Det er opp til deg om du vil gjøre det. Uansett, får filen installert på nettbrettet og deretter konfigurere SSH app for å logge inn med nøkkelfilen, ved hjelp av app instruksjoner.

Deretter bruker appen, koble til serveren. Du trenger brukernavn, selv om du bruker en nøkkel-fil (serveren må vite hvem du logger inn som med nøkkelfilen, tross alt); AWS bruker vanligvis "ubuntu" for brukernavnet for Ubuntu installasjoner; andre rett og slett gi deg root brukeren. For AWS, for å gjøre installasjonen må du skrive sudo før hver kommando siden du ikke er logget inn som root, men vil ikke bli spurt om et passord når du kjører sudo. På andre cloud verter kan du kjøre kommandoer uten sudo siden du er logget inn som root.

Ja, og forresten, fordi vi ennå ikke har et skrivebordsmiljø, vil du være å skrive kommandoer til installere programvaren. Hvis du ikke er kjent med pakken installasjonsverktøy, er nå en mulighet til å lære om dem. For Debian-baserte systemer (inkludert Ubuntu), vil du bruke apt-get. Andre systemer bruker yum, som er et kommandolinjegrensesnitt til RPM pakkebehandleren.

Installer LXDE

Fra kommandolinjen, er det på tide å sette opp LXDE, eller hvilken desktop du foretrekker . En ting å huske på er at mens du kan kjøre noe stort som kanel, spør deg selv om du virkelig trenger det. Kanel er store og uhåndterlige. Jeg bruker den på skrivebordet mitt, men ikke på mine vert servere, velger i stedet for flere lette stasjonære som LXDE. Og hvis du er kjent med stasjonære maskiner som kanel, vil LXDE føler veldig like.

Det er mange instruksjoner på nettet for å installere LXDE eller andre stasjonære, og så jeg vil ikke gjenta detaljene her. DigitalOcean har en fantastisk blogg med instruksjoner om hvordan du installerer en lignende desktop, XFCE.

Installer en VNC-server

Så du må installere en VNC-server. I stedet for å bruke TightVNC, som mange mennesker foreslår, anbefaler jeg vnc4server fordi det gir mulighet for enkel oppløsningen endres, så vil jeg beskrive kort tid.

Mens sette opp VNC-server, vil du opprette en VNC brukernavn . Du kan bare bruke et brukernavn og passord for VNC, og derfra du klarer å koble fra en VNC klient app til systemet. Imidlertid vil ikke tilkoblingen være sikker. I stedet vil du ønsker å koble til via det som kalles en SSH tunnel. SSH tunnel er i utgangspunktet en SSH-økt i serveren som brukes for bestått tilkoblinger som ellers ville gå direkte over internett.

Når du kobler til en server over Internett, kan du bruke en protokoll og en port. VNC bruker vanligvis 5900 eller 5901 for porten. Men med en SSH tunnel, lytter SSH-programmet på en port på samme lokale enhet, for eksempel 5900 eller 5901. Da VNC app, i stedet for å koble til den eksterne serveren, kobler lokalt til SSH app. SSH app i sin tur sender alle data på den eksterne systemet. Så SSH fungerer som en mellommann. Men fordi det er SSH, er alle dataene sikre.

Så nøkkelen er å sette opp en tunnel på nettbrettet. Noen VNC apps kan lage tunnelen; andre ikke kan, og du må bruke en egen app. JuiceSSH kan lage en tunnel, som du kan bruke fra andre apps. Min foretrukne VNC app, Remotix, derimot, kan gjøre selve tunnelen for deg. Det er ditt valg hvordan du gjør det, men du vil ønske å sette den opp.

Applikasjonen vil ha instruksjoner for tunnelen. I tilfelle av JuiceSSH, angir du serveren du kobler til og havnen, for eksempel 5900 eller 5901. Da har du også angi den lokale portnummeret tunnelen vil lytte på. Du kan bruke alle tilgjengelige port, men jeg vil vanligvis bruke samme port det fjerne. Hvis jeg kobler til 5901 på fjernkontrollen, vil jeg ha JuiceSSH også lytte på 5901. Det gjør det lettere å holde rett. Da vil du åpne opp VNC app, og i stedet for å koble til en ekstern server, kobler du til porten på samme tavle. For serveren du bare bruke 127.0.0.1, som er IP-adressen til selve enheten. Så for å re-iterere:


    JuiceSSH kobler, for eksempel til 5901 på den eksterne verten. Samtidig åpner det opp 5901 på den lokale enheten.
  1. VNC app kobles til 5901 på den lokale enheten. Det trenger ikke å vite noe om hva ekstern server den kobles til.

    Men noen VNC apps ikke trenger en annen app for å gjøre det tunneling, og i stedet gi tunnelen selv. Remotix kan gjøre dette; hvis du setter opp programmet ditt til å gjøre det, må du forstå at du fortsatt tunnel. Du gir den informasjonen som trengs for SSH tunnel, inkludert nøkkelfilen og brukernavn. Deretter Remotix gjør resten for deg.

    Når du får VNC app kommer, vil du være i. Du skal se en stasjonær åpen med LXDE logo i bakgrunnen. Deretter vil du ønsker å gå videre og konfigurere VNC-klient til din smak; Jeg foretrekker å styre musen med drags som simulerer en styreflate; andre mennesker liker å styre musen ved å peke på nøyaktig hvor du vil klikke. Remotix og flere andre programmer lar deg velge enten konfigurasjon.

    Konfigurere Desktop

    La oss nå konfigurere skrivebordet. Ett problem jeg hadde var å få skrivebordet for å se bra ut på min 10-tommers tablet. Dette innebar å konfigurere utseendet ved å klikke på oppgavelinjen menyen < Preferanser < Tilpasse utseendet og preget (eller kjøre fra kommandolinjen lxappearance
    )


    Jeg brukte også OpenBox egen konfigurasjonsverktøyet ved å klikke på oppgavelinjen menyen <.; Preferanser < OpenBox Configuration Manager (eller kjøre obconf
    ).


    Min større tablet-skjermen er ikke stor på 10 inches, så jeg konfigurert menylinjer og knapper og slikt til være noe stort for en komfortabel visning. Ett problem er tabletten har en så høy oppløsning at hvis jeg brukte den maksimale oppløsningen, alt var liten. Som sådan, jeg trengte å være i stand til å endre vedtak basert på det arbeidet jeg gjorde, samt basert på hvilken tablett jeg var med. Dette innebar konfigurere VNC server, men ikke LXDE og OpenBox. Så la oss se på det.

    For å endre oppløsning på fly, trenger du et program som kan håndtere RANDR utvidelser, for eksempel xrandr
    . Men TightVNC serveren som synes populær ikke fungerer med RandR. I stedet fant jeg vvnc4server Programmet fungerer med xrandr, det er derfor jeg anbefaler å bruke den i stedet. Når du konfigurerer vnc4server, vil du ønsker å gi de forskjellige oppløsninger i kommandoens -geometry alternativ. Her er et init.d tjeneste konfigurasjonsfil som gjør nettopp det. (Jeg endret dette basert på en jeg fant på DigitalOcean blogg.)

     # /bin /bashPATH = "$ PATH: /usr /bin /"! Eksport user = "Jeff" ALTERNATIVER = "- dybde 16 - geometri 1920x1125 -geometry 1240x1920 -geometry 2560x1500 -geometry 1920x1080 -geometry 1774x1040 -geometry 1440x843 -geometry 1280x1120 -geometry 1280x1024 -geometry 1280x750 -geometry 1200x1100 -geometry 1024x768 -geometry 800x600: 1 ". /lib /LSB /init-functionscase "$ 1" instart) log_action_begin_msg "Starte vncserver for user '$ {user} på localhost: $ {DISPLAY}" su $ {user} -c "/usr /bin /vnc4server $ {ALTERNATIVER } ";; stopp) log_action_begin_msg" stopping vncserver for user '$ {user} på localhost: $ {DISPLAY} "su $ {user} -c" /usr /bin /vnc4server Drepe: 1 ";; omstart) $ 0 stoppe $ 0 start;; esacexit 0 

    Nøkkelen her er ALTERNATIVER linje med alle -geometry alternativer. Disse vil dukke opp når du kjører xrandr
    fra kommandolinjen:


    Du kan bruke VNC innlogging til å endre filen i init.d katalogen (og faktisk Jeg gjorde det, ved hjelp av redaktøren heter SciTE). Men så etter å gjøre disse endringene, må du starte VNC tjenesten bare denne ene gangen, siden du endrer sine tjenesteinnstillinger. Dette vil avslutte din nåværende VNC-økt, og det er kanskje ikke starter på riktig måte. Så du trenger å logge inn gjennom JuiceSSH å starte VNC-server. Deretter kan du logge inn med VNC-server. (Du kan også hende at du må starte SSH tunnel.) Når du gjør det, vil du være i stand til å konfigurere oppløsning. Og fra da av, kan du endre oppløsningen på sparket uten å starte VNC serveren

    For å endre vedtak uten å måtte starte VNC-server, skriver du bare:.

     xrandr -s 1 < p> Erstatt 1 med tallet for oppløsningen du ønsker. På denne måten kan du endre oppløsningen uten å starte VNC-server. 

    Server Bekymringer

    Når alt er konfigurert, er du fri til å bruke programvaren du er kjent med. Den eneste haken er at vert betalt en god bit for servere som har rikelig med RAM og diskplass. Som sådan, kan du være begrenset av hva du kan kjøre basert på hvor mye RAM og kjerner. Likevel har jeg funnet ut at med bare 2 GB RAM og 2 kjerner, med Ubuntu og LXDE, jeg er i stand til å ha åpent Chrome med noen få sider, Libreoffice med et par dokumenter åpne, Geany for min kode redigering, og min egen serverprogramvaren som kjører under node.js for testing, og mysql server. Noen ganger hvis jeg får for mange Chrome faner åpne, vil systemet plutselig treg vei ned, og jeg må stenge faner for å frigjøre mer minne. Noen ganger kjører jeg MySQL Workbench og det kan bog ting ned litt også, men det er ikke dårlig hvis jeg lukker opp Libreoffice og la bare en eller to Chrome faner åpne. Men generelt, for det meste av arbeidet mitt, har jeg ingen problemer i det hele tatt.

    Og på toppen av det, hvis jeg trenger mer hestekrefter, kan jeg spinne opp en større server med 4GB eller 8GB og fire kjerner eller åtte kjerner. Men det blir kostbart og så jeg ikke gjør det for altfor mange timer.

    flere skjermer

    For moro, jeg klarer å få to skjermer går på et enkelt skrivebord, en på min større 10-tommers ASUS transformator tablet, og en på min mindre Nexus 7 alt fra min Linux server som kjører på en offentlig sky vert, komplett med et enkelt muse beveger seg mellom de to skjermene. For å oppnå dette, begynte jeg to VNC økter, én fra hver tablett, og deretter fra den med mus og tastatur, løp jeg:

     x2x-Øst -til: 1 

    Dette koblet utgangspunktet den eneste mus og tastatur til begge skjermene. Det var et morsomt eksperiment, men i mitt tilfelle, forut liten praktisk verdi fordi det ikke var som en ekte dual-skjerm på en stasjonær datamaskin. Jeg kunne ikke bevege glide vinduer mellom skjermene, og Chrome nettleseren vil ikke åpne under mer enn ett X-skjermen. I mitt tilfelle, for webutvikling, jeg ønsket å være i stand til å åpne opp Chrome-nettleseren på en tablett, og deretter Chrome Javascript feilsøkingsvinduet på den andre, men det fungerte ikke.

    I stedet hva jeg fant mer nyttig var å ha en SSH kommandolinje shell på mindre tablett, og det er der jeg ville kjøre min node.js serverkoden, som ble skrive ut debug informasjon. Så på den andre ville jeg ha nettleseren kjører. På den måten kan jeg blikk frem og tilbake uten å bytte mellom vinduer på singelen VNC innlogging på større tablet.

    Tilbake til Security

    Jeg kan ikke understate betydningen av å sørge for at du har din sikkerhet satt opp og at du forstår hvordan sikkerhets fungerer og hva konsekvensene er. Jeg anbefaler å bruke SSH med en nøkkelfil login bare, og ingen passord innlogginger tillatt. Og behandle dette som en utvikling eller tester; ikke sette kundedata på maskinen som kan åpne deg opp til søksmål i tilfelle maskinen blir kompromittert.

    I stedet for produksjonsmaskiner, fordele produksjonsservere med alle de beste praksis lagt ut av din egen IT-avdelingen sikkerhetsregler, og vertens egne regler. Ett problem jeg treffer er min utvikling maskinen må logge inn git, noe som krever en privat nøkkel. Min utvikling maskin er vert, noe som betyr at den private nøkkelen er lagret på en hosted server. Som kan eller ikke kan være en god idé i ditt tilfelle; du og laget ditt må du bestemme om du vil gjøre det. I mitt tilfelle, bestemte jeg at jeg hadde råd til risikoen fordi koden jeg tilgang til det meste åpen kildekode, og det er lite privat åndsverk involvert. Så hvis noen brøt seg inn i min utvikling maskin, ville de ha tilgang til kildekoden for en liten, men ikke-vital prosjekt jeg jobber med, og utkast til disse artiklene -. Ingen private eller intellektuelle data

    webutviklere og A Pesky Thing Called Windows

    Før jeg bryte opp dette, ønsker jeg å presentere et tema for diskusjon. I løpet av de siste årene har jeg lagt merke til at mange enkelt webutviklere bruker et oppsett ganske likt det jeg beskriver. I mange tilfeller bruker de Windows i stedet for Linux, men ideen er den samme uavhengig av operativsystem. Men hvor de skiller seg fra hva jeg beskriver er de vertskap hele sine kunde nettsider og kundedata på at en maskin, og det er ingen tunneling; i stedet, de bare skrive inn et passord. Det er ikke det jeg taler her. Hvis du gjør dette, kan du revurdere. (Jeg personlig kjenner minst tre private webutviklere som gjør dette.)

    Uansett operativsystemer, ta litt tid å forstå konsekvensene her. Først ved å logge inn med en komplett skrivebordsmiljø, du muligens bremse ned maskinen for din dev arbeid. Og hvis du rotet noe opp og må starte på nytt, i løpet av den tiden kundenes nettsteder er ikke tilgjengelig i denne perioden. Bruker du replikering? Bruker du privat nettverk? Kjører du MySQL eller annen database på samme maskin i stedet for å bruke virtuelt privat nettverk? Hele bøker kan (og har vært) skrevet om slike emner og hva de beste praksis er. Lær om replikering; lære om virtuelt privat nettverk og hvordan du kan beskytte dine databaseservere fra utsiden trafikk; og så videre. Og viktigst vurdere sikkerhetsspørsmål. Er du vert kundedata i et område som lett kan bli kompromittert? Som kunne stave L-A-W-S-U-I-T. Og det bringer meg til min konklusjon for denne serien

    KOnKlUSJOn

    Noen kommentarer på tidligere artikler har brakt opp noen gyldige poeng.; en selv brukte uttrykket "å spille." Mens jeg virkelig jeg gjør utviklingsarbeid, er jeg definitivt ikke gjør dette på produksjonsmaskiner. Hvis jeg var, det ville faktisk være å spille, og ikke være en legitim bruk for en produksjonsmaskin. Bruk SSH for produksjonsmaskiner, og plukke en redaktør å bruke og lære det. (Jeg liker vim, personlig.) Og holde kundedata på en server som er tilgjengelig bare fra et virtuelt privat nettverk. Les dette for å lære mer.

    Lær hvordan du setter opp og konfigurere SSH. Og hvis du ikke forstår alt dette, så vær så snill, praksis og lære det. Det er en million nettsteder der ute for å lære slike ting, inkludert linux.com. Men hvis du forstår og kan minimere risikoen, da, du virkelig kan få noe av arbeidet fra nesten hvor som helst. Mitt arbeid har blitt langt mer produktiv. Hvis jeg ønsker å kjøre til en kaffebar og gjøre noe arbeid, jeg kan, uten å måtte ta en laptop sammen. Tidene er bra! Lære reglene, følger beste praksis, og være produktiv

    Se tidligere tutorials.

    Hvordan sette opp ditt Linux Dev Station å jobbe hvor som helst

    Velge programvare å arbeide eksternt fra din Linux Dev Station Anmeldelser