I need to install software on Windows clients that are completely offline. That means they have no Internet access.
An example. Let's say I want to install Paint.Net. I go to a reference machine (with INet) and install Paint.Net with Chocolatey.
choco install paint.net -y
After the install is finished I have the software installed and two artifacts:
The package file "paint.net.nupkg" in %ChocolateyInstall%/lib/paint.net
and
the the installer file "paint.net.4.0.6.install.zip" in %Temp%\chocolatey.
I now put these two files on a USB stick. Then I go to the offline machine, plug in the USB stick and want to install the package.
Is it possible to install the software without modifying the package? I am aware that inside the nupkg file there is a tools/chocolateyInstall.ps1 file with a $url variable defined. But I want to install the package without changing the package content or modifying the URL by hand.
I played around with the parameters --cache and --source but with little to no luck.
I have seen that this kind of question is asked before. But never (to my knowledge) with the intend to run the installer file from the stick too (and not only the package file). So I hope this is not a duplicate.
Caching Downloads - Not Deterministic
While there are ways to set the original nupkg (with the version on it, not the one in the packages directory - use download from left side of package's page on the Chocolatey community package repository) and the cache onto a USB stick somewhere, it's not always deterministic that it will work. You can also override the cache location, so that the folder is somewhere not in TEMP. See choco config, choco config -h and choco config set cacheLocation c:\some\location to do this.
Create Your Own Packages - Better
For packages you need offline, you have the ability to manage your own packages and you can embed software right into the package. This is desired when you want to manage software offline as most things on the community repository are subject to copyright law and distribution rights (why they don't simply have the software they represent embedded).
Creating and working with your own packages is very secure, reliable, and repeatable (and can be completely offline), but it does tend to take up time. If you are doing this for yourself, then it could override any time-savings you get as a consumer using Chocolatey and the community repository.
Internalized Packages - Best
The best thing you can do here is a process called internalizing, where you download and extract the package, download all of the resources and embed them in the package (or put them somewhere local/UNC share), edit the scripts to use those embedded/local resources and recompile the package.
This allows you to take advantage of existing package logic without the issue of the internet.
For more details see Recompiling Packages and Package Internalizer - Automatically Recompile Packages.
NOTE: As a side note, we are thinking of offering the ability to auto recompile with Chocolatey Pro edition and not just the Business edition.
Organization Use of Chocolatey
Most organizations using Chocolatey are doing some combination of creating packages and recompiling packages, because they need absolute trust and control over those packages when being used in production scenarios.
Related
I am curious to know if there are methods where I can add additional packages to the anaconda installer. I am basically looking for a solution for creating an anaconda installer which has some extra python packages added along with it. Thus the participants to whom I give the installer need not be worrying about Internet connectivity or to add additional commands.
This is meant for an introductory hands-on python session. Hence the objective is to make the whole installation process less confusing as possible to the participants of the session.
I am aware of using docker as well as using environments. I am looking for something more simpler, say as seamless as anaconda installation for my participants.
Currently, I am thinking of doing the following.
1) Provide the .tar.gz file of the packages along with the installer
2) After installation and creating environments, install the libraries using pip from the .tar.gz
python -m pip install c:\mymodule\great.tar.gz
Any method which is simpler than the above one is welcome.
From the conda documentation on creating custom channels:
If you do not wish to upload your packages to the Internet, you can
build a custom repository served either through a web server or
locally using a file:// URL.
The instructions on that page tell you how to create a local custom repository from conda packages. They're aimed at people who are building their own packages but as far as I can see you can also use the existing packages that you can download from the repositories at https://repo.continuum.io/pkgs/.
You can then use the file:// URL of that repository in the -c specification of conda create and/or conda install commands to set up the environment for your users to work in.
at work we have a central, read-only, Linux Anaconda installation, and several projects need library packages for their individual project members.
Is there a way to conda install packages in a writable area set aside for each project?
Our Linux servers are also not directly web connected, but we can transfer data from a Windows machine that is. Is there a way for the windows conda to download data for our Linux install in such a way that I can transfer the downloaded files to Linux and then finish the install on Linux , with the conda linux not needing a direct web connection?
Thanks in advance :-)
The best answer to this question is a bit oblique: the Anaconda Distribution is designed for a single user on a single system with unrestricted access to the Internet. Any other use is considered "off label" and YMMV, though there are no license restrictions in place preventing you from trying to use it as you see fit. Anaconda Enterprise is the commercial product that is specifically designed for multi-user, server-deployed Anaconda with firewall restrictions. Security, governance, indemnification, support, collaboration, etc. etc. Check out https://www.continuum.io/ for more details.
But there are "work around" ways to achieve what you want, albeit complicated ones. For it to be reliable, reproducible, and maintainable you're going to end up reimplementing a lot of what is in Anaconda Enterprsie. Here are some tips:
Check out the "conda in multi-user environments" documentation
Check out the "Centralized Anaconda installation" documentation
Regular user alice for project foo can do conda create -p /nfs/project/foo/envs/custompython --offline anaconda; conda activate /nfs/project/foo/envs/custompython; conda install pkg1 pkg2 pkg3
You're going to run into ownership/permission issues. If you have sensible umask values then when alice's colleague bob tries to update pkg2 in the foo project he'll discover that he can't unlink the files alice wrote there. There is stuff you can do (as the IT admin) with chown, or alice can do with chmod, but its all a bit of a bother and there are lots of ways you can paralyze a conda environment because it is expecting "writability" to be binary for a particular environment. There is a long history in the conda GH issue tracker of people (myself included) shooting themselves in the foot by starting a conda env setup with one account and then making mods with another account that bork out half way through, leaving everything inconsistent.
Be careful about .condarc files. My advice: avoid them everywhere but in the base Anaconda installation (say, inside /opt/anaconda/.condarc). All sorts of weird stuff can happen when multiple overlaying .condarc files come together (the docs reference above discusses this).
People can create their own environments in an "offline" mode so long as the packages specified in those new environments (and their dependencies) are a subset of the packages available in the base environment (or subsequently added to the package cache), taking into account versions as well, of course.
You can download packages using your online Windows machine by grabbing them from repo.continuum.io and from anaconda.org. Make sure you download them for the right platform. But the challenge: you need to download a set of packages that will satisfy the dependencies of the package you want to install. There isn't a super easy way to get that information when you're offline.
Once you drop new packages into the Linux system's package cache be sure to re-run conda index.
Beware installing packages directly from their tarballs: this will not pick up any dependencies and does what is called a "force" install. So doing conda install /path/to/conda/pkg-ver.tar.bz2 is actually most similar to doing conda install --force --no-deps pkg=ver (though not identical, to be sure). --force means the install will happen NO MATTER WHAT, even if it will break your environment (violate existing package dependencies), and --no-deps means you won't get any of the dependencies of pkg installed.
I'm unhappy how nuget handles client-side packages, so I want to try bower, as per the process described here. I want the tool to fit into my workflow, not vice versa.
Note that what I'm interested in is bower - I just want client-side package manager, not those grunt/gulp build tools.
What I've done:
Everything in that post. I'm on VS2013 Update 4, I installed those 3 extensions, and the windows version of nodejs, and then bower.
What I want to do, is more or less a .NET/VS-ish worflow:
When I install some package, it pulls the entire repo! I only want the sort of files you'd get in a nuget package, e.g. foo.js, foo.min.js, foo.css, foo.min.css and webfonts.
I want those files to go to the right places, so scripts to ~/scripts/lib, stylesheets to ~/styles/lib and fonts to ~/fonts. Right now it's just dumping everything in bower_components which is no better than what nuget does for me.
I'd like to rename those files to the way we do it in the .NET world, so foo-2.0.1.js and foo-2.0.1.min.js, etc.
This is how I did it:
Apparently Bower pulls down all the junk, and there's nothing you can do about it! Seems silly to me coming from a nuget background, but that's how it works in this tool.
I moved the files from the bower_components directory, to the appropriate places, using a javascript-based build tool. I used "Gulp", which has tooling support in VS2013-Update3 onwards.
I didn't change the filenames. The node stack seems to work better that way.
I have an installer implemented with "Packages" which contains the payload and after running some plugins and a post install script it successfully installs the product.
The same package bundle is used for making updates too, as we run it in background with root privileges and it overwrites the current/old installation files.
We now have the requirement to make a lightweight installer having the components (different Packages inside the product) in a web location to be downloaded and installed.
As I know that this is possible in other systems as Windows/InstallShield with "Releases of Web Type", I would like to know if this is possible in OS X. Otherwise, I will have implement it all from scratch (packages management, download, packages versions compare to make selective updates, privileges escalation, etc).
Well, it was long ago and I almost started doing a web installer from scratch but then I found out that the option is in Packages itself. Hope this helps.
It is the "Package Reference" option.
According to the Packages documentation
A Package Reference lets you use a package that is hosted on a web
server or a removable media and to which you may not have a direct
access. This package will not be built during the built phase.
I think that any referenced package will have its own pre-post-scripts so there would be no problem because of the limited options in the Package Reference. But I need to test it.
We run a system on Centos 5.5 and install our software using one RPM containing all of our software. When we need to apply a hot fix or patch the current system is simply to stick on a tar and untar it.
I'm trying to develop a trackable, repeatable system for applying hot fixes and patches but I'm a little unsure as to what role RPM plays in this process.
From what I understand if we up the version number and reinstall even with just one file changed then RPM will blast the whole lot. This requires us being absolutely sure that noone has put another hotfix on the system that we're not aware of as it will be replaced.
Is it possible to make an RPM that contains JUST the new files and apply that on top of an existing RPM? How would that affect subsequent upgrades of the system?
The problem is changing files locally installed by the rpm and forgetting about them.
If you use this as a hotfix procedure, right after the hotfix you should build the new rpm and then deploy that new rpm.
If people are allowed to put hotfix after hotfix on top of a machine without ever committing it to the normal process, you're inviting disaster.
One thing you can do to be reminded of the fact that you have hotfixes lying around is to use
rpm -q --verify (your rpm name)
This will print a list of files that have been changed since the rpm was installed. That way you at least know which files were patched and should be taken into account.
The point of RPM is to have repeatable, verifiable installs. You should generate a new RPM with the update rolled into it (via a patch or new upstream source).
Splitting up your monolithic package would allow you to upgrade parts individually.
You can use deltarpm (but I don't recommend it, see bellow).
Having old rpm and new rpm (on build machine) you can generate delta using deltarpm tool.
Using deltarpm tool on box where software is installed you can then automagically upgrade old rpm to the new rpm (and downgrade it back if needed).
I don't like it because if any (non config) file provided by old rpm will get change, you will not be able to install the fix. Moreover deltarpm it is not production-ready tool. You have been warned.
As an alternative for deltarpm I will advice to split your software to few smaller RPMs and deliver subset of new RPMs as a hotfix. This is most commom approach.