Installare dike6 su fedora 25

Fedora Linux Programmi
#1

Buongiorno a tutti. Sono un avvocato e sto cercando di installare il programma dike 6, che mi è indispensabile per utilizzare il certificato di firma remota che ho appena acquistato da Infocert. Ho scaricato la versione per Ubuntu dal sito di Infocert, l’ho convertita in rpm con alien, ma non riesco ad installare. Ecco l’output da terminale:

sudo rpm -i dike6-6.4.8-2.x86_64.rpm
[sudo] password di andrea:
errore: Dipendenze fallite:
liblber-2.4.so.2(OPENLDAP_2.4_2)(64bit) necessario a dike6-6.4.8-2.x86_64
libldap_r-2.4.so.2(OPENLDAP_2.4_2)(64bit) necessario a dike6-6.4.8-2.x86_64
[andrea@HP Scaricati]$ sudo rpm -ivh dike6-6.4.8-2.x86_64.rpm --nodeps
Preparazione in corso… ################################# [100%]
il file / dell’installazione di dike6-6.4.8-2.x86_64 entra in conflitto con il file del pacchetto filesystem-3.2-37.fc24.x86_64
il file /opt dell’installazione di dike6-6.4.8-2.x86_64 entra in conflitto con il file del pacchetto filesystem-3.2-37.fc24.x86_64
il file /usr dell’installazione di dike6-6.4.8-2.x86_64 entra in conflitto con il file del pacchetto filesystem-3.2-37.fc24.x86_64
il file /usr/share dell’installazione di dike6-6.4.8-2.x86_64 entra in conflitto con il file del pacchetto filesystem-3.2-37.fc24.x86_64
il file /usr/share/applications dell’installazione di dike6-6.4.8-2.x86_64 entra in conflitto con il file del pacchetto filesystem-3.2-37.fc24.x86_64
il file /usr/share/doc dell’installazione di dike6-6.4.8-2.x86_64 entra in conflitto con il file del pacchetto filesystem-3.2-37.fc24.x86_64
il file /usr/share/applications dell’installazione di dike6-6.4.8-2.x86_64 entra in conflitto con il file del pacchetto intel-linux-graphics-installer-1.4.0-23.intel20161.x86_64
[andrea@HP Scaricati]$ sudo dnf remove filesystem-3.2-37.fc24* intel-linux-graphics-installerintel-linux-graphics-installer*
Nessuna corrispondenza per l’argomento: filesystem-3.2-37.fc24*
Nessuna corrispondenza per l’argomento: intel-linux-graphics-installerintel-linux-graphics-installer*
Errore: Nessun pacchetto marcato per la rimozione.
[andrea@HP Scaricati]$ sudo dnf remove filesystem* intel-linux-graphics*
Dipendenze risolte.
Errore: L’operazione porterà alla rimozione dei seguenti pacchetti protetti: systemd, systemd-udev, dnf.

Come si può notare i problemi sono due, ovvero la presunta mancanza di dipendenze e, più grave, il conflitto con il pacchetto filesystem che è una dipendenza di alcuni pacchetti protetti come sistemd e quindi non si può rimuovere. Il primo problema ho provato ad aggirarlo in questo modo: ho aperto il pacchetto rpm con il gestore di archivi ed ho provato ad estrarre direttamente la cartella /opt/dike6. A questo punto dentro ho trovato l’eseguibile, ma lanciando il programma mi suggeriva la mancanza di alcune librerie. Ho installato la libreria libipeg8 che era una di quelle mancanti da un rpm esterno e per le altre ho capito che bastava creare dei link simbolici perché in realtà ci sono ed è il programma che non le vede. A quel punto, però, si è verificato un ultimo scoglio che non sono riuscito a superare: mi diceva a terminale che non trovava o non caricava il plugin xcb. Ho provato sia a creare dei link simbolici che a copiare le librerie direttamente nella cartella dike6, ma il messaggio di errore compare comunque. Ho provato a cercare in google e ho trovato possibili soluzioni, come quella indicata al link http://stackoverflow.com/questions/17106315/failed-to-load-platform-plugin-xcb-while-launching-qt5-app-on-linux-without, che però sembra siano attuare in fase di compilazione del pacchetto. Qualcuno mi può aiutare, per cortesia? Grazie sin da ora

Sono riuscito a far funzionare almeno parzialmente l’applicazione in questo modo. Ho scaricato il file .deb per ubuntu, l’ho convertito in rpm con alien, ho creato una cartella dike, ho messo all’interno l’".rpm", l’ho scompattato con rpm2cpio “nome_file.rpm” | cpio -i -d -v. A questo punto ho provato a lanciare l’eseguibile, ma mi indicava la mancanza di alcune librerie. Le ho scaricate tutte una per una, o nel formato deb (quelle originarie per ubuntu) per poi convertirle o scaricando gli rpm corrispondenti (per esempio di fedora 17 che da qualche parte si trovano ancora) ed ho provveduto a scompattare all’interno di apposita cartella creata (per ciascun rpm da scompattare) per poi spostare il tutto dentro la cartella dell’applicazione dike.

Allo stato attuale se lancio l’applicazione non mi da più alcun tipo di segnale di mancanza di librerie o altro da terminale, tuttavia non riesco ad usare la firma remota, perché se provo ad inserire user e password mi dice “errore sconosciuto”, mentre in macchina virtuale, con dentro Ubuntu, la stessa applicazione apre una finestra per inserire un codice “otp”. L’unico problema che mi resta, quindi, è riuscire ad ottenere lo stesso risultato su Fedora, per non dover necessariamente usare un altro sistema per una sola funzione di un’applicazione che non va. Ho provato anche a disabilitare momentaneamente il firewall, ma non sembra essere questo il problema. Se qualcuno più esperto di me vuol provare a risolvere il problema, segnalo che al link http://blog.dellunto.net/?p=220 sono indicati alcuni file di configurazione da editare per poter utilizzare la normale “chiavetta”. Mi chiedo se non sia qualche problema con qualche altro file che provoca l’errore di cui dicevo, o se c’è ancora qualcosa che manca affinché possa funzionare il generatore di codici otp. Grazie in anticipo. Avvcivil

#2

Il pacchetto è fatto male ovviamente, non dovrebbe rivendicare la paternità di quelle cartelle. Non rimuovere i pacchetti di sistema, per carità :smiley:

Hai due possibilità: modificare il file rpm a mano e correggerlo, oppure forzare l’installazione del pacchetto con l’opzione –force e successivamente reinstallare, con la stessa opzione, filesystem-3.2-37.fc24.x86_64 e intel-linux-graphics-installer-1.4.0-23.intel20161.x86_64.

#3

[quote=frafra]Il pacchetto è fatto male ovviamente, non dovrebbe rivendicare la paternità di quelle cartelle. Non rimuovere i pacchetti di sistema, per carità :smiley:

Hai due possibilità: modificare il file rpm a mano e correggerlo, oppure forzare l’installazione del pacchetto con l’opzione –force e successivamente reinstallare, con la stessa opzione, filesystem-3.2-37.fc24.x86_64 e intel-linux-graphics-installer-1.4.0-23.intel20161.x86_64.[/quote]

Riepilogo la situazione (ho tolto quello che non interessa più). Ormai ho la certezza: l’unica difficoltà è quella di connettere l’applicazione con il Server. Ho provato sia ad importare una per una tutte le librerie da Ubuntu a 32 bit che ad installare la versione a 64 bit. Sono riuscito ad eliminare tutti gli avvertimenti da terminale ma soprattutto ho importato i files di configurazione da Ubuntu ed ecco che l’account di firma remota è stato inserito. Continua, tuttavia, ad essere impossibile inviare al server dove si trova il certificato di firma remota l’impulso ad inviare l’otp (one time password), da inserire in apposita finestra che neppure si apre. Ho necessità, quindi, ormai, solo di indicazioni su come facilitare la connessione (probabilmente configurando diversamente il firewall). Attualmente la connessione è imposta su “Nessun proxy”. Purtroppo non so cosa sia un proxy. Se nel mio caso è necessario crearne uno, sarei grato a chiunque mi potesse dare indicazioni. Infine segnalo che ho un Nas ed anche quello ha il suo firewall che, da quanto ho capito, si sostituisce a quello del router. Non credo però sia quello il problema perché se anche tengo il Nas spento, la situazione non cambia.

Per chi sia interessato, comunque, ribadisco che la soluzione sperimentata come funzionante (fatta eccezione per il problema che ho detto) è stata:
scaricare il file per installare dike6 su ubuntu a 64 bit; convertirlo con alien; prendere l’rpm e scompattarlo in una directory a piacere, creata apposta, con il comando rpm2cpio nome_file.rpm | cpio -i -d -v (naturalmente al posto di nome_file va messo il nome del file convertito). Occorre quindi spostarsi nella cartella /otp/dike6 che in questo modo è stata creata e lanciare “./Dike” da terminale. Verrà segnalata la mancanza di alcune librerie. Ho cercato quelle per Ubuntu a 64 bit, le ho convertite in rpm con identico sistema ed ho incollato di volta in volta solo i file che, nel pacchetto così scompattato, si trovano in /usr/lib, fino a che non è più segnalato nulla. Ho fatto lo stesso anche per ldap, usando la libreria per Ubuntu e mi ha segnalato la mancanza di libasl2.so e di altre librerie che ho provveduto ad aggiungere con lo stesso sistema. Ho provato, per evitare il problema “errore sconosciuto” a prendere la cartella “.dike” da Ubuntu e metterla nella home di Fedora. Funziona perché l’account viene creato (come in Ubuntu), ma non si riesce a comunicare con il server. Grazie di tutto, spero che qualcuno esperto nei problemi di comunicazione via internet mi possa aiutare a compiere l’ultimo passo.

#4

Grazie per aver condiviso la soluzione, ma la sconsiglio (è meno sporco fare come detto sopra).

Detto questo, ora la questione non mi pare sia legata alla installazione, ma all’utilizzo del software in sé. Se il software è installato correttamente e ti puoi connettere normalmente ad internet non hai bisogno di toccare alcun firewall. Sicuro che nell’installazione non sia sfuggito qualcosa? Non da errori?

#5

[quote=frafra]Grazie per aver condiviso la soluzione, ma la sconsiglio (è meno sporco fare come detto sopra).

Detto questo, ora la questione non mi pare sia legata alla installazione, ma all’utilizzo del software in sé. Se il software è installato correttamente e ti puoi connettere normalmente ad internet non hai bisogno di toccare alcun firewall. Sicuro che nell’installazione non sia sfuggito qualcosa? Non da errori?[/quote]

Sicuramente la soluzione che ho proposto é tutt’altro che ottimale, ma evita i conflitti che si erano verificati e che rendevano o impossibile scaricare pacchetti dai repository usando la connessione “htps”, che avevo dovuto disabilitare e che invece ora funziona ovvero, anche se di questo non sono sicuro, anche con l’opzione “force” rendevano difficoltosa la installazione . Inoltre ho potuto, procedendo in quel modo, rendermi conto della mancanza di alcune librerie inizialmente non segnalata, tra le quali libasl2.so. Comunque in effetti l’impossibilità di connettermi al server é un mistero. Ho provato a mettere come server proxy l’indirizzo del Nas e come credenziali quelle per accedere al medesimo, ma mi segnala che il server proxy non supporta le connessioni “https”. Non so se può significare qualcosa, ma quando ho provato a mettere la firma su Android e condividere una cartella di Fedora, ho constatato che invece di vedere il pc Android vedeva solo il Nas, con il suo indirizzo nella rete domestica. Lanciando da terminale non mi risultano errori. Gli unici due errori li segnala Dike e sono o l’impossibilità di comunicare con il server, se metto “nessun proxy”, oppure il server proxy non supporta le connessioni https, se metto il Nas come proxy. Ho attiva la web station sul Nas e non so se sarebbe utile disabilitare, dato che l’ho attivata un giorno per caso oppure configurarla diversamente.

P.S: a proposito di --force, ricordavo bene:

sudo rpm -i dike6-6.4.8-2.x86_64.rpm --force
errore: Dipendenze fallite:
liblber-2.4.so.2(OPENLDAP_2.4_2)(64bit) necessario a dike6-6.4.8-2.x86_64
libldap_r-2.4.so.2(OPENLDAP_2.4_2)(64bit) necessario a dike6-6.4.8-2.x86_64

Ho inserito manualmente quelle dipendenze, prendendole da ubuntu e facendo la conversione in rpm per poi scompattare il pacchetto e prendere le librerie. Comune ora la connessione sembra esserci perché facendo il test mi dice connessione ok, tuttavia se tolgo l’account di firma remota non riesco a rimetterlo e compare sempre l’errore sconosciuto.

#6

Ma il pacchetto RPM che hai preso, per che sistema sarebbe? Puoi mettere un link?

#7

Certo, molto volentieri. Il pacchetto originario, convertito in rpm, è per Ubuntu (come se fosse l’unico sistema Gnu/Linux al Mondo; perdonate lo sfogo, ma se c’è una cosa che ho capito da quando uso Fedora è che è questa ultima a cui si deve la maggior parte delle innovazioni e trovo assurdo che venga trascurata). L’indirizzo è il seguente:
https://www.firma.infocert.it/prodotti/dike6.php. In fondo alla pagina c’è il link per scaricare il file per Ubuntu (dalla versione 14.4), a 32 bit o 64 bit.

#8

Ah, ora si capisce tutto. Secondo me l’idea migliore sarebbe creare un ambiente Ubuntu minimale dentro Fedora ed installare questo pacchetto. L’utente finale non se ne accorgerebbe nemmeno di stare utilizzando librerie di Ubuntu. Mai usato debootstrap?

#9

Non l’ho mai usato, però l’idea è geniale. Come si fa? Avevo pensato anche io a qualcosa del genere, perché quando ho provato a mettere owncloud nel Nas (non sono riuscito ed ho lasciato perdere, perché ho risolto in altro modo) avevo installato, seguendo istruzioni in rete, un ambiente debian minimale (dentro il Nas e con chroot). Ho pensato si potesse fare qualcosa anche con Fedora del genere, ma non sapevo da che parte cominciare. Come si fa? :slight_smile:
Una precisazione importante: non ero riuscito a far funzionare own cloud, ma ad installare l’ambiente debian minimale, si. Non mi ricordo se si trattava del metodo proposto o qualche altro, ma non mi sembra che si trattasse proprio di debootstrap.

#10

Qualcosa tipo…

$ debootstrap --no-check-gpg  trusty ubuntu http://mirrors.aliyun.com/ubuntu
#11

[quote=frafra]Qualcosa tipo…

$ debootstrap --no-check-gpg  trusty ubuntu http://mirrors.aliyun.com/ubuntu

Grazie. Ho provato a dare il comando e sta scaricando. Mi è solo venuto un dubbio: dovevo creare una directory particolare? In caso contrario, devo lavorare in qualche directory per installare dike? Grazie mille davvero ancora :slight_smile: :slight_smile:

#12

Ti dovrebbe creare una cartella che si chiama ubuntu. Dopo devi entrare nell’ambiente dando un paio di mount ed eseguendo chroot. Roba tipo…

[code]# mount --bind /dev ubuntu/dev

mount --bind /proc ubuntu/proc

mount --bind /sys ubuntu/sys

mount --bind /run ubuntu/run

chroot ubuntu[/code]

A questo punto scarichi il pacchetto nell’ambiente con wget e lo installi con dpkg, e dai un apt-get -f install e… Insomma, tutti quei riti strani che si fanno su Ubuntu :wink:

#13

[quote=frafra]Ti dovrebbe creare una cartella che si chiama ubuntu. Dopo devi entrare nell’ambiente dando un paio di mount ed eseguendo chroot. Roba tipo…

[code]# mount --bind /dev ubuntu/dev

mount --bind /proc ubuntu/proc

mount --bind /sys ubuntu/sys

mount --bind /run ubuntu/run

chroot ubuntu[/code]

A questo punto scarichi il pacchetto nell’ambiente con wget e lo installi con dpkg, e dai un apt-get -f install e… Insomma, tutti quei riti strani che si fanno su Ubuntu ;)[/quote]

Perfetto, gentilissimo!!! Ho usato un tempo ubuntu e debian, anche se anni fa, quindi dovrei riuscire. Appena riesco faccio sapere. Nel frattempo davvero ancora un grazie enorme di vero cuore!!! :slight_smile: :slight_smile: :slight_smile:

Ho ancora necessità di aiuto. Ho provato ad installare l’ambiente minimale, ma ci vuole almeno anche apt get perché diversamente devo installare a mano tutte le dipendenze e non finisco più. Cercando in rete sembra si debba installare anche schroot; ho qualche problema, tuttavia, a configurarlo. In particolare vorrei capire che directoy devo mettere (sembra che tenda a montare il sistema nella cartella /var; vorrei essere sicuro che vada bene). Mi chiedo anche se devo configurare anche chroot e se le due cartelle devono coincidere oppure no. Mi ha creato una directory ubuntu nella home che appartiene però a root.
Ho trovato una guida specifica per ubuntu qui: http://wiki.ubuntu-it.org/Programmazione/DebootstrapChroot. Mi posso fidare a seguirla? Sembra che dovrebbe funzionare anche apt-get.

#14

debootstrap dovrebbe avere una opzione per specificare pacchetti extra: aggiungici apt.

#15

Ecco un aggiornamento su questa disavventura (tutta colpa di Infocert, non di Fedora). Seguendo la guida che ho trovato per Ubuntu precise, aggiornata (è bastato modificare il file di configurazione togliendo un paio di voci ormai obsolete, come mi segnalava il terminale, naturalmente sostituendo “zesty” a “precise” e “amd64” a “i386”) e dopo avere installato l’ultima versione (Zesty), perché con la 14.4 c’era un bug in un pacchetto, proprio in caso di installazione con chroot, che impediva di proseguire, dopo essere riuscito ad installare tutto il necessario e dopo aver creato dei link simbolici all’interno di chroot, sono riuscito a far funzionare l’applicazione proprio come in Ubuntu, con una differenza. Questa volta la finestra con la richiesta dell’otp al server si apre, ma poi mi da errore sconosciuto. Sembra che non sia possibile, tuttora, comunicare con il server. Ciò è molto strano perché se faccio il test sulla connessione mi dice ok (succedeva anche installando l’applicazione in Fedora, però in quel caso non si apriva la finestra con la richiesta di invio di un otp dal server) . Non riesco neppure ad inserire le credenziali per il certificato di firma remota, a meno che le prendo dalla cartella “.dke” che si è creata nella macchina virtuale con dentro Ubuntu e la metto nella home di Fedora. A cosa può essere dovuto il problema? Una possibilità che mi è venuta in mente è quella di un possibile “disturbo” delle librerie presenti in Fedora, anche se mi sembra strano perché il link simbolico punta direttamente al file presente in Ubuntu (chroot). Nonostante tutto continuo a pensare che l’idea di usare debootstrap è comunque giusta perché, sia pure con un po’ di pazienza, sicuramente sono riuscito ad installare meglio l’applicazione, in modo molto più pulito ed ordinato e senza errori da terminale. Preciso anche che il lancio dell’applicazione avviene da Fedora con un link simbolico che si collega all’eseguibile dentro chroot. Sono state importanti le guide trovate all’indirizzo http://wiki.ubuntu-it.org/Programmazione/DebootstrapChroot. Il link simbolico l’ho creato ispirandomi a quanto ho trovato al link http://forum.ubuntu-it.org/viewtopic.php?t=21275, ma non ho seguito tutto quello che c’è scritto perché è un documento un po’ vecchiotto; magari invece avrei dovuto, per poter lanciare direttamente l’applicazione da dentro Fedora anziché da dentro chroot (appoggiandomi su quello). A quanto sembra la home viene ora montata automaticamente in chroot. Se provo a lanciare da li (ovvero da chroot) puramente e semplicemente Dike, non trova nessun display. Forse dovrei installare dentro Ubuntu xorg (e/o wayland) e compagnia bella, ma non so se ne vale la pena e se risolverebbe il problema. Ciao e grazie. Avvcivil

#16

Buongiorno,

anche io sono nella stessa situazione purtroppo…
Il “programma” presente nella penna di firma, dopo aver sistemato i problemi di dipendenze rende un misero “segmentation fault”…
Per quanto riguarda dike6 mi sono arreso dopo aver perso diverse ore bisticciando con le dipenze…
Fino ad ora comunque ho risolto solamente con una installazione su virtualbox di WindowsXP, ma non voglio arrendermi…

#17

[quote=avvcivil]A cosa può essere dovuto il problema? Una possibilità che mi è venuta in mente è quella di un possibile “disturbo” delle librerie presenti in Fedora, anche se mi sembra strano perché il link simbolico punta direttamente al file presente in Ubuntu (chroot).
…]
Forse dovrei installare dentro Ubuntu xorg (e/o wayland) e compagnia bella, ma non so se ne vale la pena e se risolverebbe il problema. Ciao e grazie. Avvcivil[/quote]

Nessun disturbo di librerie, il sistema è separato, al più può non essere impostata una variabile di ambiente legata a X o qualche limitazione di SELinux. Hai impostato la variabile DISPLAY? Su internet hai varie guide legate al come avviare applicazioni grafiche in chroot, hai già provato a seguirne qualcuna?

#18

Bene che tu non voglia arrenterti :slight_smile:
Il segmentation fault è quasi sicuramente legato alle dipendenze non realmente soddisfatte. Siccome il pacchetto non è fatto per Fedora ed è di difficile conversione, un ambiente separato (non virtualizzato, giusto usando chroot) secondo me è la strada migliore. avvcivil l’ha fatto ed è a un passo dalla risoluzione del problema (probabilmente gli manca solo da settare la variabile DISPLAY). Ti consiglio di adottare lo stesso approccio.

#19

Questo thread è vecchissimo, ma direi che è tuttora attuale.

Mi sono imbattuto in problemi simili con Dike Go Sign e Fedora 31.

L’unica soluzione che sono riuscito a trovare (sbattendoci le corna diverse ore…) è stata creare un container docker Ubuntu in cui ho installato gnome-desktop, Firefox, sshd, Dike e varie dipendenze dello stesso. E’ una mezza porcata ma almeno così facendo posso eseguire Dike “da Fedora” tramite ssh -X root@ip_del_container Dike