We have a TeamCity build server on Windows, and we're having a problem with teams trying to install different versions of global packages.
I want to restrict global package install, but i'm drawing a blank on any info on this. I've already removed ACL's on the .npmrc because people were messing with proxy and registry global settings. I need a way to restrict global package installation as well.
Is it as simple as removing write access to the node_packages folder under ~/AppData/Roaming/npm/?
Related
I have a WPF app that I am planning on deploying with the Windows Application Packaging Project in Visual Studio that makes the MSIX bundle for installations and future updates. The installer automatically installs the app in C:\Program Files\WindowsApps. This is fine until the program needs to cache some data or it needs to modify the appsettings file since the app does not have permission to get to these resources.
Is there a setting I can change in the packaging properties/manifest so it can install somewhere else so I can avoid these problems?
Indeed, only the Windows can write in %ProgramFiles%\WindowsApps when installing the msix package (by design). If your app is writing log files or other data inside the installation folder it will crash.
You need to either update your code to write to %AppData% or, if you don’t have access to the code, use the Package Support Framework to fix it. You can read more about here:
Package Support Framework (aka PSF)
The PSF brings support for API redirection and hooking. Thus, you can fix an app that failed to write a file in the installation folder (this is no longer allowed) and redirects it to a recommended location, or maybe simply update the app’s working directory.
As mentioned above, you cannot write in the install location of an MSIX package - this is by design.
For apps that are no longer under active developer indeed using the Packafe Support Framework is the only way to fix them. However, from what I see you are preparing to launch the app, so you have access to its code.
In this scenario, it is recommended you save all your app settings in the AppData\Roaming folder. For apps deployed as MSIX Windows will automatically redirect it under the Packages folder, but that is handled automatically by the OS, so you don't need to worry about it. More details below.
How to save data under AppData\Roaming instead of AppData\Local\Packages
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.
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.
I have configured MAC OS X environment (SDKs, licenses, etc) under current user for build server and would like to reuse all the settings by a build agent. Jenkins was chosen as a good option but for some reason during installation it created a new user jenkins and launch the app under it, causing the environment setup to be not accessible (no SDKs, no licenses are found anymore).
Is it possible to install jenkins under current user?
Probably it could be installed under jenkins but then launched under current user?
Any other good options for me to consider are appreciated.
Try this: http://www.sailmaker.co.uk/blog/2013/04/02/advanced-jenkins-for-ios-and-mac/#Installing-Jenkins-itself
I’m also going to recommend installing Jenkins via Homebrew, to avoid
some nonsense in Jenkins’ own installer whereby it puts itself in
/Users/Shared/. You really don’t want that.
If you're free to reinstall however you'd like, I'd recommend re-installing as the user you want to use, using whatever type of install you prefer, and then simply copy over the old Jenkins data directory to the new installation's location, and then changing the permissions in that directory.
That is to say, the directory containing the config, plugin and job information (it may be something like /usr/lib/jenkins, but could vary).
Then, chown -R the data directory using the user:group info you want to use so Jenkins has access to the files.
I have used this type of method in the past to transfer all the data from one install to another totally separate install on the same box, and it has worked well (one could use this method to transfer the data to an install on another box, as well).
Note: I would highly recommend making a full backup of the data directory before doing this, in case anything goes awry.
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.