Në lidhje me ndryshimin e legjislacionit në lidhje me shërbimet e besimit ("Për shërbimet e besimit elektronik" Ukraina), në ndërmarrje u shfaq nevoja për disa departamente të punojnë me çelësat e vendosur në tokena (në këtë moment, çështja e numrit të çelësave fizikë ende është e hapur).
Si njĂ« mjet me kostot mĂ« tĂ« ulĂ«ta (falas), menjĂ«herĂ« u zgjodh . Serveri nĂ« Ubintu 18.04 filloi tĂ« funksionojĂ« falĂ« publikimit dhe u testua me sukses nĂ« disa memorje flash (pĂ«r shkak tĂ« mungesĂ«s sĂ« tokenit nĂ« atĂ« moment). Nuk u zbuluan probleme tĂ« veçanta, pĂ«rveç monopolizimit (rezervimit pĂ«r pĂ«rdoruesin) nĂ« atĂ« kohĂ«. ĂshtĂ« e qartĂ« qĂ« pĂ«r tĂ« organizuar qasjen pĂ«r disa pĂ«rdorues (tĂ« paktĂ«n dy, pĂ«r fillim) Ă«shtĂ« e nevojshme tĂ« ndahen ata nĂ« kohĂ« dhe tĂ« detyrohen tĂ« punojnĂ« me radhĂ«.
Doli çështja: Si tĂ« bĂ«jmĂ« qĂ« gjithçka tĂ« funksionojĂ« me sa mĂ« pak mundimâŠ
Një pjesë e thjeshtë
Variant I. Disa lidhje për skedarët .bat, pra
a) Lidja e çelësit të aksesit.
b) Shkëputja e qëllimshme.
Pika "b" është e diskutueshme, prandaj u vendos të jepet një sasi kohe për të punuar me çelësin për 3 minuta.
Karakteristika e klientit usbip është se pas nisjes së tij ai mbetet i pezulluar në konsolë, pa ndërprerje të sesionit të konsolës, lidhjen mund të mbyllësh "ashpër" nga ana e klientit dhe gjithashtu nga ana e serverit.
Këtu është ajo që funksionoi normalisht:
e para: lidhja on.bat
usbip -a 172.16.12.26 4-1
msg * "Nënshkrimi/tokeni nuk janë të aksesueshëm ose janë të zëna "e dyta: shkëputja off.bat
ping 127.0.0.1 -n 180
taskkill /IM usbip.exe /Fduke mos shpresuar në vetëdijen e përdoruesit, skenat u bashkuan në token.bat
on.bat | off.batCila është rezultati: të gjithë skedarët janë në një dosje, ekzekutimi me skedarin token.bat, nëse lidhja mbyllet nga përdoruesi menjëherë ka një mesazh për papërshtatshmërinë e çelësit, në rastin tjetër, vetëm pas 180 ping-eve. Rreshtat e kodit të paraqitur mund të pajisen me "@ECHO OFF" dhe ndihmën e konsolës në "> nul" për të mos e shokuar shumë përdoruesin, por për ekzekutim në testim nuk është e nevojshme. Prova fillestare në memorjen USB tregoi se gjithçka ishte e parashikueshme - e besueshme - e saktë. Ndërkohë, nga ana e serverit nuk nevojiten asnjë manipulime.
Natyrshëm, gjatë punës me token, gjithçka nuk shkoi si e pritur: kur lidhej fizikisht në menaxherin e pajisjeve, tokeni regjistrohej si 2 pajisje (WUDF dhe kartë inteligente), ndërsa në rrjet si WUDF (edhe pse për kërkesën e PIN-it kjo është e mjaftueshme).
Gjithashtu doli se âtaskkillâ i dhunshĂ«m nuk Ă«shtĂ« aq i egĂ«r, dhe mbyllja e lidhjes nĂ« klient Ă«shtĂ« problematike dhe madje nĂ«se arrin ta bĂ«sh kĂ«tĂ«, nuk garanton mbylljen e saj nĂ« server.
Duke sakrifikuar të gjitha konsolat në klient, skenari i dytë mori formën:
ping 127.0.0.1 -n 180 > nul
taskkill /IM usbip.exe /F /T > nul
ping 127.0.0.1 -n 10 > nul
taskkill /IM conhost.exe /F /T > nuledhe pse efikasiteti i tij është nën 50%, pasi serveri vazhdonte të mendonte se lidhja nuk ishte mbyllur.
Problemet me lidhjen çuan në mendime për modernizimin e pjesës server.
Pjesa server
ĂfarĂ« nevojitet:
- Të çaktivizohen përdoruesit e pafavorshëm nga shërbimi.
- Të shikohet kush aktualisht përdor (apo akoma zë) tokenin.
- Të kuptohet nëse tokeni është i lidhur me kompjuterin e vet.
Për të zgjidhur këto probleme, u vendos të përdoren shërbimet crontab dhe apache. Diskretësia e rikthimit të gjendjes së monitorimit për pikat 2 dhe 3 tregon se sistemi i skedarëve mund të vendoset në ramdrive. Në /etc/fstab u shtua rreshti
tmpfs /ram_drive tmpfs defaults,nodev,size=64K 0 0
Në rrënjë u krijua një dosje script me skenarët: shkëputje-rikthim të tokenit usb_restart.sh
usbip unbind -b 1-2
sleep 2
usbip bind -b 1-2
sleep 2
usbip attach --remote=localhost --busid=1-2
sleep 2
usbip detach --port=00marrja e listës së pajisjeve aktive usblist_id.sh
usbip list -r 127.0.0.1 | grep ':' |awk -F ":" '{print $1}'| sed s/' '//g | grep -v "^$" > /ram_drive/usb_id.txtmarrja e listës së IP-ve aktive (me përmirësim të mëtejmë për shfaqjen e identifikuesve të përdoruesve) usbip_client_ip.sh
netstat -an | grep :3240 | grep ESTABLISHED|awk '{print $5}'|cut -f1 -d":" > /ram_drive/usb_ip_cli.txtvetë crontab duket kështu:
* /5 * * * * /!script/usb_restart.sh > /dev/null 2>&1
* * * * * ( sleep 30 ; /!script/usblist_id.sh > /dev/null)
* * * * * (sleep 10 ; /!script/usbip_client_ip.sh > /dev/hull)Pra, kemi: çdo 5 minuta një përdorues i ri mund të lidhet, pa marrë parasysh kush ka punuar me tokenin. Në serverin http është lidhur me një sy grafik dosja /ramdrive në të cilën ruajnë 2 skedarë tekstorë që tregojnë për gjendjen e serverit usbip.
Pjesa në vijim: «E shëmtuar në ambalazhim»
II opsioni. Të ofrosh përdoruesve një ndërfaqe më pak frikësuese. Duke u shqetësuar për faktin se përdoruesit kanë versione të ndryshme të Windows me frameworke të ndryshme dhe drejtime të ndryshme, qasja më pak problematike se nuk e gjeta (sigurisht që jam për C#, por jo në këtë rast). Mund të ekzekutohen skedarët bat nga ndërfaqja edhe në sfond, të minimizuar, por pa një provë të duhur, personalisht mendoj se duhet të visualizohet për të mbledhur pakënaqësitë e përdoruesve.
Ndërfaqja dhe pjesa programore zgjidhën detyrat e mëposhtme:
- Të tregojë nëse tokeni është i zënë në këtë moment.
- Në fillim, konfigurimi fillestar me gjenerimin e skedarëve bat "të saktë" që realizojnë ekzekutimin dhe ndërprerjen e seancës së punës me serverin e tokenit. Në ekzekutimet pasuese, realizimi i modit "shërbimi" me fjalëkalim.
- Kontrolli i disponueshmërisë së lidhjes me serverin, nga i cili kryhet pyetja për zënien ose shfaqen mesazhe për probleme. Në rinisjen e lidhjes, programi fillon automatikisht të punojë në mënyrë normale.
Puna me serverin WEB është realizuar me mjete të shtesës fphttpclient.
ka gjithashtu një vazhdim të mendimeve lidhur me temën e artikullit, ashtu si dhe një entuziazëm fillestar të pjesshëm për produktin VirtualHere me karakteristikat e tij...
Burimi: habr.com
