Munti kunhavon el Tunnelblick sen funkcii kiel root

Dumrestanta malfermita AppleScript povas observi unu Tunnelblick-profilo kaj munti SMB-kunhavon kiel la ensalutinta uzanto, sen root-hoko aŭ sudo sen pasvorto.

La VPN-kliento bezonas privilegian helpon por rekonfiguri la reton, kaj tiu fakto trovas tro larĝan aplikon al ĉio ĉirkaŭe. Skripto, kiu muntas dosierkunhavon, ne bezonas root, ĉar la kunhavo apartenas al la seanco de la ensalutinta uzanto kaj al la akreditiloj de tiu uzanto. Forigi la muntadon el la privilegia vojo forigas la bezonon de sudo-reguloj, root-hokoj kaj modifoj al kunligitaj aplikaĵoj. Restas malgranda dumrestanta apleto, kiu observas unu profilon kaj faras unu provon.

Kial ĉi tio apartenas al la uzantsesio

Muntita volumo estas eco de la seanco, kiu muntis ĝin. La seanco de alia uzanto ne vidas ĝin, kaj muntado posedata de root kondutas alie ol tiu, kiun Finder kreis. Teni la muntadon en la uzantsesio konservas tiun semantikon.

Privilegiaj helpiloj ekzistas por la partoj, kiuj vere bezonas ilin: krei tunel-interfacon, ŝanĝi itinerojn, ĝisdatigi la solvilon. Munti SMB-kunhavon ne estas unu el tiuj partoj. Trakti ĝin kvazaŭ ĝi estus, devigas elekton inter sudo sen pasvorto kaj root-skripto, kiu funkcias dum neniu ĉeestas. Ambaŭ estas pli grandaj riskoj ol la problemo pravigas, kaj la aliro per la uzantsesio tute evitas la elekton.

La propraj konektaj hokoj de Tunnelblick ne anstataŭas ĉi tion, ĉar ili funkcias ekster la labortabla seanco kaj ilia ordo rilate al la skriptoj de la kliento ne estas difinita. Pridemandi la staton el uzanta apleto estas pli malgranda mekanismo kun malpli da supozoj.

Pruvu unue permane, ke la kunhavo funkcias

Aŭtomatigo ne povas provizi itinerojn, permeson aŭ konton, kiu ne ekzistas. Konektu la VPN permane kaj malfermu la kunhavon en Finder antaŭ ol skribi iun skripton. Se tio malsukcesos, la skripto malsukcesos pli konfuze.

Notu la tri valorojn, kiujn la skripto uzos: la profilan nomon precize kiel Tunnelblick listigas ĝin, la kunhavan URL-on kaj la volumennomon, kiun Finder montras post la muntado. La volumennomo gravas ĉar la kontrolo de ekzistanta muntado uzas ĝin, kaj kontrolo nur laŭ la nomo estas komforta gardo, ne pruvo de la identeco de la servilo. Uzu nomon unikan sur la maŝino. Poste konfirmu, ke la servilo entute respondas.

smbutil view //files.corp.example
osascript -e 'tell application "Tunnelblick" to get state of first configuration whose name is "Office"'
mount | grep -i smbfs

La unua komando pruvas, ke la servilo respondas, la dua pruvas, ke la profila nomo solviĝas, kaj la tria montras, kiel aspektas sukcesa muntado. Kaptu ĉiujn tri antaŭ ol aŭtomatigi ion ajn.

Legu la profilan staton el Tunnelblick

Tunnelblick elmontras siajn agordojn kaj iliajn statojn per AppleScript, kaj tio estas la sola hoko, kiun ĉi tiu dezajno bezonas. La stato, pri kiu temas, estas la ĉeno raportita por ĝuste tiu profilo, ne la ĉeesto de la aplikaĵo.

Pridemandado havas sekvojn, kiujn indas mencii. Rekonekto pli mallonga ol la intervalo povas pasi nerimarkite, kaj la apleto tute ne vidas la transiron. Tio estas akceptebla por muntada gardo kaj neakceptebla por io, kio devas reagi al ĉiu evento. Se vi bezonas eventan fidelecon, ĉi tio estas la malĝusta mekanismo anstataŭ mekanismo, kiu bezonas pli mallongan tempon. Elektu la intervalon kun tiu kompromiso en menso.

property attempted : false

on idle
    set profileName to "Office"
    set shareURL to "smb://files.corp.example/OfficeTeam"
    set volName to "OfficeTeam"
    tell application "Tunnelblick" to set vpnState to state of first configuration whose name is profileName
    if vpnState is not "CONNECTED" then
        set attempted to false
        return 20
    end if
    tell application "Finder" to set mounted to (exists disk volName)
    if (not mounted) and (not attempted) then
        set attempted to true
        try
            mount volume shareURL
        end try
    end if
    return 20
end idle

Eksportu ĝin kiel aplikaĵon kun la opcio resti malfermita, kaj lanĉu ĝin en la ensalutinta seanco anstataŭ per sudo.

Muntu unufoje, poste ĉesu provi

La flago «provita» estas tio, kio malhelpas, ke ĉi tio fariĝu buklo divenanta akreditilojn. Post kiam la apleto provis, ĝi atendas, ke la konekta stato ŝanĝiĝu antaŭ ol reprovi.

Tiu konduto estas intenca. Kunhavo, kiu rifuzas la muntadon, kutime rifuzas ĝin pro kialo, kiun reprovo ne povas ripari, kaj ripetitaj provoj igas unu peton rivero da ili. La flago restarigas, kiam la profilo forlasas la konektitan staton, do vera rekonekto produktas ĝuste unu novan provon. Forlasi kaj relanĉi la apleton ankaŭ restarigas ĝin, kaj tio estas la permana superregado. Neniu vojo kaŝas malsukceson; ambaŭ lasas ĝin videbla en Finder.

La skripto portas neniun pasvorton, kaj tiel ĝi devus resti. Lasu la muntadan operacion demandi, kaj lasu la ŝlosilĉenon fari tion, kion la organizo subtenas. Enigi akreditilon en URL-on transformas komfortan skripton en sekreton, kiun oni devas rotacii.

Kion la helpilo ne povas fari

Tri limojn indas skribi apud la apleto. Ĝi ne povas elĵeti okupatan volumon post reta fiasko, ĝi ne povas garantii, ke DNS kaj la servilo pretas kiam la stato diras konektita, kaj ĝi ne reagas al ĉiu rekonekto.

La unua limo plej gravas en la praktiko. Kunhavo, kies servilo malaperas, lasas volumon, kiu ŝajnas muntita kaj blokas ĉe aliro, kaj la ĝentila solvo estas fini dosierajn operaciojn kaj elĵeti antaŭ planita malkonekto. La dua klarigas la plej multajn malsukcesajn unuajn provojn: la tunelo staras dum la solvilo ankoraŭ ne atingis, do atendu kaj poste muntu permane unufoje por konfirmi. La tria estas la pridemanda kompromiso de pli frue, ne cimo riparinda.

Por neservata maŝino aŭ administrata floto, ĉi tiu dezajno estas la malĝusta formo. Uzu muntadan politikon posedatan de la administranto anstataŭ etendi labortablan apleton en privilegian servon.

Rilataj artikoloj