Lige kun ŝanĝoj en leĝaro pri fidaj servoj ("Pri elektronikaj konfidaj servoj" Ukrainio), la entrepreno bezonas plurajn fakojn labori kun ŝlosiloj situantaj sur ĵetonoj (nuntempe, la demando pri la nombro da aparataj ŝlosiloj ankoraŭ estas malfermita. ).

Kiel ilo kun la plej malalta kosto (senpage), la elekto tuj falis usbip. La servilo sur Ubintu 18.04 ekfunkciis danke al la publikigo Malsovaĝigi USB/IP kaj sukcese provita sur pluraj poŝmemoriloj (pro la manko de ĵetono en tiu tempo). Neniuj specialaj problemoj krom monopolposedo (rezervado por la uzanto) estis identigitaj ĉe tiu punkto en tempo. Estas klare, ke por organizi aliron por pluraj uzantoj (almenaŭ du, por komenci), necesas dividi ilian aliron ĝustatempe kaj devigi ilin labori laŭvice.

La demando estis: Kiel mi povas fari ĝin kun la plej malgranda kvanto da dancado por ke ĉio funkciu por ĉiuj...

La parto estas mallerta

Opcio XNUMX. Pluraj ŝparvojoj al bat-dosieroj, nome
a) Konektante la alirŝlosilon.
b) Intencite malkonekti.

Alineo "б» polemika, do oni decidis doni la kvanton da tempo por labori kun la ŝlosilo je 3 minutoj.

La propreco de la usbip-kliento estas, ke post kiam ĝi estas lanĉita, ĝi restas pendanta en la konzolo; sen interrompi la konzolan sesion, vi povas fermi la konekton "malglate" de la klienta flanko kaj ankaŭ de la servila flanko.

Jen kio bone funkciis por ni:

unue: konekto sur.vesperto

usbip -a 172.16.12.26 4-1
msg * "Подпись/токен недоступны или заняты "

dua: haltigo off.vesperto

ping 127.0.0.1 -n 180
taskkill /IM usbip.exe /F

Sen fidado de la konscio de la uzanto, la manuskriptoj estis kombinitaj en ĵetono.vesperto

on.bat | off.bat

Kio okazas: ĉiuj dosieroj estas en la sama dosierujo, lanĉita de la token.bat-dosiero, se la konekto estas fermita la uzanto tuj ricevas mesaĝon pri la ŝlosilo neatingebla, en alia kazo, nur post 180 ping-oj. La supraj kodlinioj povas esti ekipitaj per "@ECHO OFF" kaj la konzola direkto al "> nul" por ne tro ŝoki la uzanton, sed ne necesas fari testadon. La komenca "kuro" sur USB-disko montris, ke ĉio estis antaŭvidebla, fidinda kaj klara. Plie, neniuj manipuladoj estas postulataj de la servila flanko.

Kompreneble, kiam oni laboris rekte kun la ĵetono, ĉio ne iris kiel atendite: kun fizika konekto en la aparato-administranto, la ĵetono estas registrita kiel 2 aparatoj (WUDF kaj inteligenta karto), kaj kun retkonekto nur kiel WUDF (kvankam tio sufiĉas por peti PIN-kodon).

Ankaŭ rezultas, ke la brutala "taskkill" ne estas tiel severa, kaj fermi la konekton ĉe la kliento estas problema kaj eĉ se ĝi sukcesis, ĝi ne garantias fermi ĝin por li sur la servilo.

Oferinte ĉiujn konzolojn sur la kliento, la dua skripto prenis la formon:

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  > nul

kvankam ĝia efikeco estas malpli ol 50%, ĉar la servilo obstine daŭre konsideris la konekton malfermita.

Problemoj kun la konekto kondukis al pensoj pri ĝisdatigo de la servila flanko.

Servila parto

Kion vi bezonas:

1. Malkonektu neaktivajn uzantojn de la servo.
2. Vidu kiu nuntempe uzas (aŭ ankoraŭ pruntas) la ĵetonon.
3. Vidu ĉu la ĵetono estas konektita al la komputilo mem.

Ĉi tiuj problemoj estis solvitaj per la crontab kaj apache servoj. La diskreta naturo de reverkado de la stato de la monitoraj rezultoj de punktoj 2 kaj 3, kiuj interesas nin, indikas, ke la dosiersistemo povas troviĝi sur la ramdrive. Aldonita linio al /etc/fstab

tmpfs   /ram_drive      tmpfs   defaults,nodev,size=64K         0       0

Skripto-dosierujo kun skriptoj estis kreita en la radiko: unmounting-mounting the token 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=00

ricevante liston de aktivaj aparatoj usblist_id.sh

usbip list -r 127.0.0.1 | grep ':' |awk -F ":" '{print $1}'| sed s/' '//g | grep -v "^$" > /ram_drive/usb_id.txt

akirante liston de aktivaj IP-oj (kun posta modifo por montri uzantidentojn) usbip_client_ip.sh

netstat -an | grep :3240 | grep ESTABLISHED|awk '{print $5}'|cut -f1 -d":" > /ram_drive/usb_ip_cli.txt

la crontab mem aspektas jene:

*/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)

Do ni havas: ĉiujn 5 minutojn nova uzanto povas konektiĝi, sendepende de kiu laboris kun la ĵetono. La dosierujo /ramdrive estas konektita al la http-servilo per simbolligo, en kiu 2 tekstdosieroj estas konservitaj, montrante la staton de la usbip-servilo.

Sekva parto: "Malbela en envolvaĵo"

Opcio II. Por iom plaĉi al la uzanto per almenaŭ iu malpli timiga interfaco. Konfuzitaj de la fakto, ke uzantoj havas malsamajn versiojn de Vindozo kun malsamaj kadroj, malsamaj rajtoj, malpli problema aliro ol Lazaro Mi ne trovis ĝin (mi kompreneble estas por C#, sed ne ĉi-kaze). Vi povas lanĉi vespertajn dosierojn de la interfaco en la fono, minimumigita, sed sen taŭga testado, mi persone opinias: vi devas bildigi ĝin por kolekti uzantmalkontenton.

La sekvaj taskoj estis solvitaj per la interfaco kaj programaro:

1. Montras ĉu la ĵetono estas nuntempe okupata.
2. Ĉe la unua lanĉo, la komenca aranĝo implikas generi la "ĝustajn" vespertajn dosierojn, kiuj efektivigas la lanĉon kaj interrompon de sesio kun la ĵetonoservilo. Ĉe postaj komencoj, efektivigo de la "serva" reĝimo uzante pasvorton.
3. Kontrolante la ĉeeston de konekto kun la servilo, rezulte de kiu ĝi sondas ĉu ĝi estas okupata aŭ montras mesaĝojn pri problemoj. Kiam komunikado estas rekomencita, la programo aŭtomate ekfunkcias en normala reĝimo.

Labori kun la TTT-servilo estas efektivigita uzante la aldonan fphttpclient-aldonaĵon.

ĉi tie estos ligilo al la nuna versio de la kliento

estas ankaŭ pliaj konsideroj pri la temo de la artikolo, kaj ankaŭ parta komenca entuziasmo por la produkto VirtualHere kun ĝiaj trajtoj...

fonto: www.habr.com