Lors de l'installation d'applications via le centre logiciel ou via un fichier DEB, celles-ci sont généralement installées sur l'ensemble du système, pour tous les utilisateurs.
Est-il possible d'installer une application pour un seul utilisateur?
Lors de l'installation d'applications via le centre logiciel ou via un fichier DEB, celles-ci sont généralement installées sur l'ensemble du système, pour tous les utilisateurs.
Est-il possible d'installer une application pour un seul utilisateur?
Selon ce que vous voulez accomplir, il peut y avoir différentes façons de faire fonctionner le logiciel (ou du moins de lui donner un semblant de fonctionnalité).
L'installation d'un logiciel se résume à plusieurs égards à la mise à disposition de ressources ou à l'accès à des éléments déjà présents sur le système.
Que vous parliez d’accorder l’accès aux imprimantes ou de permettre à un utilisateur d’exécuter des programmes dans un répertoire donné, il existe des moyens de le faire. Bien qu’ils soient natifs d’Ubuntu, ces types de solutions vont généralement (bien sûr) être ajouté après le fait d'une installation .deb.
Voici deux classes générales de contrôle post-installation pouvant être ajoutées. Notez que, dans le bon environnement, par exemple, lorsqu'une stratégie de groupe étroitement contrôlée est en place, cela pourrait être plus facile une fois le système de base en place. Ce type d'autorisation peut même être lié à LDAP ou à un système similaire pouvant donner une authentification et une autorisation par groupe ou utilisateur.
Contrôle de la visibilité
J'ai moi-même eu une situation quelque peu similaire, mais dans mon cas, les utilisateurs n'étaient pas (encore) très sophistiqués (tous âgés de moins de 7 ans). Pour moi, masquer les menus de Gnome et supprimer les lanceurs de postes de travail fonctionnaient.
Supprimer le bit exécutable des répertoires élimine la possibilité pour les processus de les rechercher ou de les parcourir. Cela peut effectivement les rendre invisibles et, du point de vue de l'utilisateur, les rendre indisponibles. Si vous avez une stratégie système par défaut qui crée des menus basés sur l'accès aux fichiers, par exemple, vous pouvez mettre en place ce type de solution esthétique, puis la faire fonctionner pour des installations ultérieures avec peu d'effort supplémentaire.
Contrôle de l' exécution Le contrôle de la ressource peut être effectué via des autorisations Unix, des profils apparmor, des autorisations SELinux, etc. Il peut y avoir d'autres niveaux de filtrage de contrôle qui peuvent entrer en jeu en fonction de l'application. En l'absence de solutions plus ciblées, vous devrez peut-être écrire des wrappers autour de certains programmes pour contrôler l'accès des utilisateurs ou des processus.
Eh bien
dpkg
ne vous aidera pas car ce n'est pas son objectif de conception. Il veut être un recensement unique, appartenant à la racine, des paquets installés sur un système.La seule chose qui me vient à l’esprit est simplement d’extraire le paquet et d’essayer de placer les fichiers manuellement dans le répertoire personnel.
Cependant, cela ne fonctionnera que pour certaines choses. De nombreux packages sont scindés en morceaux (fichiers exécutables ou scripts
/usr/bin
, bibliothèques/lib
et autres éléments/usr/share
, etc.) et ces emplacements sont codés en dur par les scripts de construction. Ainsi, si vous essayez d’~
intégrer quelque chose comme cela , cela casserait. Vous pourriez passer des heures à décompresser les dépendances, mais vous pourriez aussi faire quelque chose de utile, comme trouver un remède contre le cancer ou absorber une partie de la beauté du monde.Vous feriez beaucoup mieux de simplement récupérer une version non empaquetée de quiconque écrit le logiciel. Presque tous les logiciels libres sont disponibles sous forme d'archive compressée en tant que source, saisissez-le et construisez-le. Tu ne fais pas le
make install
pas. Votre application est construite, placez-la où vous le souhaitez.la source
/etc/init
, recherche les fichiers de configuration dans/etc
, ou contient d’autres chemins codés en dur../configure --prefix=$HOME/local
.Je ne sais pas trop à ce sujet, mais il semble, d’autres réponses, que vous pourrez peut-être installer un paquet dans un autre répertoire au lieu de
/
avecdpkg
, en utilisant le--root
paramètre, puis faire unchroot
dans le répertoire dans lequel se trouvait le paquet " installed "in (qui peut bien sûr être un répertoire dans le répertoire personnel de l'utilisateur).Pour installer un package pour un utilisateur autre que
root
, vous pouvez éventuellement utiliser le processus ci-dessus à lafakechroot
place dechroot
.Avertissement : Je n'ai pas essayé cela, et ne pas avoir beaucoup d' expérience au moment de l' écriture avec
dpkg
ouchroot
, mais de ce que je ne sais sur ces outils, ce processus juste pourrait fonctionner.Liens contenant des informations pouvant être utiles aux personnes souhaitant obtenir des résultats
chroot
sansroot
capacités:chroot
fakechroot
)Mise à jour
J'ai maintenant fait un peu avec des choses qui touchent à ce sujet et en ai découvert plus ...
Fragments (blocs de construction de l'environnement local):
chroot(1)
Complet (fournisseurs d’environnement local complets):
chroot(1)
,mount --bind
,binfmt_misc
et binaires en cours d' exécution d'autres architectures utilisant qemu-espace utilisateurRésumé : en émulant ou en disposant réellement les privilèges root localement, les packages DEB peuvent être installés pour un environnement local.
la source
Vous pouvez probablement utiliser l'
--root
option dedpkg
pour installer dans un autre répertoire. Mais vous rencontrerez probablement des problèmes si l’application recherche des éléments à des endroits fixes, tels que/etc
.En bref, je ne pense pas qu'il existe un moyen simple.
la source
Vous pouvez modifier la propriété du fichier exécutable afin qu'un seul utilisateur puisse l'exécuter. Ensuite, si nécessaire, vous pouvez supprimer l'application des menus d'autres utilisateurs.
la source
~/bin
. Il y a une ambiguïté dans cette question de savoir si Takkat souhaite restreindre l'accès / la visibilité d'une application multi-utilisateur ou s'il souhaite installer une application mono-utilisateur. Vos questions et arranger utilisent la première interprétation et les autres supposent la dernière.Douteux.
Les deb sont principalement des archives qui sont extraites à la racine de votre système de fichiers lors de l'installation (plus de la configuration). Si vous voulez les installer uniquement pour un utilisateur, vous devez les installer dans le dossier / home / user. Même si vous le faisiez, cela ne fonctionnerait pas, par exemple, les applications binaires n'atterriront pas dans / usr / bin (ou similaire) et le système ne les trouvera pas si vous essayez de les lancer. De même, les bibliothèques, etc. seraient inutiles, car le système ne saurait pas qu'il y en ait quelque part dans / home. Vous pouvez essayer l’ approche par force brute et ajuster la variable PATH pour pointer là où vous avez extrait les fichiers de l’archive deb, mais ce ne serait pas seulement VERY problèmes de compatibilité (par exemple, les entrées de menu ne fonctionneraient pas, car GNOME examinait les fichiers .desktop dans / usr / share / applications).
En outre, si vous installez un package uniquement pour certains utilisateurs, des problèmes de dépendance insolites risquent de se produire. Si un autre package installé par un utilisateur était en conflit avec un autre installé par vous-même, des problèmes liés à la gestion des packages pourraient apparaître.
Tous ces problèmes rendent extrêmement difficile la gestion des packages séparément pour les utilisateurs. Il semble donc impossible de les installer pour un seul utilisateur, car l'idée derrière le .debs ne le permet pas.
la source