[tex-live] Installing TeX Live via Windows deployment
daleif at math.au.dk
Thu Feb 5 15:34:12 CET 2015
> From: tex-live [tex-live-bounces at tug.org] on behalf of Siep Kroonenberg [siepo at cybercomm.nl]
> Sent: 05 February 2015 13:04
> To: tex-live at tug.org
> Subject: Re: [tex-live] Installing TeX Live via Windows deployment
> On Wed, Feb 04, 2015 at 10:07:36AM +0000, Lars Madsen wrote:
> > Our IT department would like to be able to provide LaTeX via their windows deployment system (currently Win7)
> > I've been thinking a bit about this. Of course they can just run the installer. But I think they'll like something unattended and the net installer may fail. They could manage their own mirror (or I could do that for them, but again it installation is often very slow and might fail).
> install-tl has a -profile option for an unattended install. The
> source may be a local rsync repository. Then you would just have to
> remove the TeX Live Manager menu entry afterwards and and lock
> things down with ACLs. All of this can be scripted with minimal
> digging around in the internals of the TL installer. You could
> download and unzip a zipped repository from the LAN, if the
> reliability of the LAN itself is a concern.
I know about the profile. But no-one in the IT department know
anything about LaTeX or would like to setup any local repos.
> > (2) PCs with only one expected user, thus changes to c:\texlive should be allowed by the user
> The GUI TLMGR tries to decide whether the permission level of the
> user matches that of the person who installed the system. Things may
> get messy if you try to get around that. Vista and later have
> something called a virtual store, where registry- and filesystem
> access is redirected to if the user does not have the necessary
> permissions. That has to be avoided at all cost.
> So if a user of a single-user workstation is not an administrator, I
> would keep it simple and make it a user install, and just accept the
> inconsistencies croppping up in a roaming profile.
I'm not even sure if the deployment system even know who the user is
going to be. It is even possible to run something as a user wehn you
are admin on a windows?
> c:\texlive should not get redirected, and install-tl has options not
> to change the registry (path, file associations) and not to create
> menu shortcuts. This could be delegated to something like w32client,
> with a menu entry for TLMGR added, assuming that the IT people find
> a good way to trigger such a script.
The deployment runs the script. So it is not a problem. Knowing who
the user is, is a problem.
> > I have not yet been through all the details of TLWinGoo so I don't quite know where the menu items and file associations go, are they added to USER or SYSTEM?
> In an admin install, the menu items go to the all users menu, and in
> a user install to the user menu. Path settings and file associations
> go to the HKLM- and the HKCU registry hives respectively.
> Admin or non-admin is first set when TLWinGoo is loaded. The
> installer gui can change admin to non-admin ($opt_nonadmin).
> By the way: user menus roam and path settings, but file associations
> do not. For our installation, I had to devise a workaround for that.
> But nowadays we have managed workspaces which try to manage file
> associations but did not make things better.
Under an admin installation, what is the difference between the
manager in the menu and say the PS viewer (don't remember the
name). The only problem I have in the deployment installation (when
installing as admin) if the fact the the manager ends up needing admin
rights to run. But the PS viewer of source does not.
Where is the difference there?
Perhaps then I'll have to give up at this end and see if the
deployment people can do some magic.
There is no problem, doing this if we know the user and if we can
execute something as that particular user. But I'm not sure what the
deployment is capable of (other than it is running with admin rights)
More information about the tex-live