En relació amb els canvis en la legislació sobre els serveis de confiança ("Sobre els serveis de confiança electrònics" Ucraïna), l'empresa necessita que diversos departaments treballin amb claus situades en fitxes (de moment, la qüestió del nombre de claus de maquinari encara està oberta). ).

Com a eina amb el cost més baix (gratuït), l'elecció va caure immediatament usbip. El servidor d'Ubintu 18.04 va començar a funcionar gràcies a la publicació Domar USB/IP i provat amb èxit en diverses unitats flash (a causa de la manca d'un testimoni en aquell moment). En aquell moment no es van identificar problemes especials que no siguin la propietat del monopoli (reserva per a l'usuari). És evident que per organitzar l'accés de diversos usuaris (almenys dos, per començar), cal dividir-los en el temps i obligar-los a treballar per torns.

La pregunta era: com ho puc fer amb el mínim de ball perquè tot funcioni per a tothom...

La part és maldestra

opció 1. Diverses dreceres als fitxers bat, és a dir
a) Connectar la clau d'accés.
b) Desconnectar deliberadament.

Paràgraf "б"és controvertit, per la qual cosa es va decidir donar la quantitat de temps per treballar amb la clau en 3 minuts.

La particularitat del client usbip és que després de llançar-lo, roman penjat a la consola sense interrompre la sessió de la consola, es pot tancar la connexió "aproximadament" des del costat del client i també des del costat del servidor;

Aquí teniu el que ens va funcionar bé:

primer: connexió on.bat

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

segon: tancament apagat.bat

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

Sense dependre de la consciència de l'usuari, es van combinar els scripts token.bat

on.bat | off.bat

Què passa: tots els fitxers es troben a la mateixa carpeta, llançat pel fitxer token.bat, si es tanca la connexió l'usuari rep immediatament un missatge sobre que la clau no està disponible, en un altre cas, només després de 180 pings. Les línies de codi indicades es poden equipar amb "@ECHO OFF" i la direcció de la consola a "> nul" per no impactar massa l'usuari, però no és necessari fer proves. La "execució" inicial en una unitat USB va demostrar que tot era previsible, fiable i clar. A més, no es requereix cap manipulació des del costat del servidor.

Naturalment, quan es treballa directament amb el testimoni, tot no ha anat com s'esperava: amb una connexió física al gestor de dispositius, el testimoni es registra com a 2 dispositius (WUDF i una targeta intel·ligent), i amb una connexió de xarxa només com a WUDF (tot i que això és suficient per demanar un codi PIN).

També resulta que el brutal "taskkill" no és tan greu, i tancar la connexió al client és problemàtic i, fins i tot si va tenir èxit, no garanteix tancar-lo al servidor.

Després d'haver sacrificat totes les consoles del client, el segon script va prendre la forma:

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

tot i que la seva eficàcia és inferior al 50%, ja que el servidor continuava tossudament considerant la connexió oberta.

Els problemes amb la connexió van fer pensar en l'actualització del costat del servidor.

Part del servidor

El que necessiteu:

1. Desconnecteu els usuaris inactius del servei.
2. Vegeu qui està utilitzant (o encara prenent en préstec) el testimoni.
3. Comproveu si el testimoni està connectat a l'ordinador.

Aquests problemes es van resoldre mitjançant els serveis crontab i apache. La naturalesa discreta de reescriure l'estat dels resultats del seguiment dels punts 2 i 3 que ens interessen indica que el sistema de fitxers es pot localitzar a la unitat RAM. S'ha afegit una línia a /etc/fstab

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

S'ha creat una carpeta de scripts amb scripts a l'arrel: 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

obtenint una llista de dispositius actius 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

obtenció d'una llista d'IP actives (amb modificació posterior per mostrar els ID d'usuari) usbip_client_ip.sh

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

el crontab en si té aquest aspecte:

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

Així que tenim: cada 5 minuts es pot connectar un nou usuari, independentment de qui hagi treballat amb el testimoni. La carpeta /ramdrive està connectada al servidor http mitjançant un enllaç simbòlic, en el qual es guarden 2 fitxers de text, que mostren l'estat del servidor usbip.

Part següent: "Lleig en un embolcall"

Opció II. Per complaure una mica l'usuari amb almenys una interfície menys intimidant. Desconcertat pel fet que els usuaris tenen diferents versions de Windows amb diferents marcs, diferents drets, un enfocament menys problemàtic que Lázaro No el vaig trobar (per descomptat sóc per C#, però no en aquest cas). Podeu executar fitxers bat des de la interfície en segon pla, minimitzats, però sense proves adequades, personalment sóc del parer: cal visualitzar-los per recollir la insatisfacció dels usuaris.

La interfície i el programari van resoldre les tasques següents:

1. Mostra si el testimoni està ocupat actualment.
2. En el primer llançament, la configuració inicial consisteix a generar els fitxers bat "correctes" que implementen l'inici i la interrupció d'una sessió amb el servidor de testimonis. En els inicis posteriors, implementació del mode "servei" mitjançant una contrasenya.
3. Comprovació de la presència d'una connexió amb el servidor, com a resultat de la qual enquesta si està ocupat o mostra missatges sobre problemes. Quan es reprèn la comunicació, el programa comença a funcionar automàticament en mode normal.

El treball amb el servidor WEB s'implementa mitjançant el complement addicional fphttpclient.

aquí hi haurà un enllaç a la versió actual del client

també hi ha més consideracions sobre el tema de l'article, així com un entusiasme inicial parcial pel producte VirtualHere amb les seves característiques...

Font: www.habr.com