When we use a YAML file to install packages like this below
nginx:
pkg.installed
Is there any convenient way to cache the installing binary files used by SaltStack, and reuse them with Saltstack later? With these caches, we can ask SaltStack to precisely reproduce the installing (provisioning) process on another machine (with the same Linux distribution installed) at the binary level.
We know that there are other tools that provide this kind of binary-level reliability in different ways. For example, docker images and AWS AMIs; Nix manages packages by storing both binary packages and hash values over them.
The pkg.installed state uses the operating system's package manager to check if the package is installed and install the package if needed. So there's nothing to cache unless your operating system's package manager provides that type of functionality.
Related
I'm working on a Linux system (a based of OpenWRT version) that has not much storage (<3MB) and no active internet connection, however I need to be able to publish to a MQTT-Broker some outputs. Is there a way for me to install just the publisher part of Mosquitto to save space or another way to solve this issue?
Without a LOT more information about the system this question is basically impossible to answer. e.g. we have no idea about what OS is being used...
But for a system with such tightly constrained storage your best option will probably to build the components you need from scratch that way you have complete control over what gets installed.
You could build the mosquitto tools and then strip them before copying just the binary you want (and any require libraries) to the system.
If you install from pretty much any Linux package management system you are likely to get all the tools plus man pages which will inflate the install footprint.
EDIT -
But all that said, a quick look at the available packages for OpenWRT implies that the existing packages that include both the broker and the command line tools would use 129kb (99 + 30 and is less if you don't need SSL 85 + 28) when installed (this assumes the pre-requisites are already installed)
https://openwrt.org/packages/table/start?dataflt%5BDescription_wiki*%7E%5D=mosquitto
GitHub recently released a container registry alongside their package registry. What is the difference? When would it be better to use one or the other? Do we need both?
Packages are generally simple: they are essentially an archive (i.e. zip file) that contains contents (code libraries, application executables, etc.) and a manifest file (json document, xml file, etc) that describes those contents with a package name and version number (at a minimum).
ie:- npm,pip and composer packages.
Container images are also simple, but they're more like an archive (i.e. a zip file) than a package.
ie:- nginx, redis etc
Verdict:- if some libs repetitively used in any project then we can create package and use in project .while for all project based dependencies we need to choose container to run this. Yes we need both.
After debating this with a Docker-using friend for a while I think I've found a satisfactory explanation:
Packages are for modules of code which are compiled together into an
Application.
Containers are for Applications which are compiled together into a
Server.
This is a bit confused by the fact that a Package can contain a standalone Applications, and Containers will often use package managers like Apt to install these applications. I feel like this is an abuse of package management due to a legacy where we didn't have Containers. Eventually I would expect most Applications will be delivered in Container form.
In order to ease the installation process of RabbitMQ, I want to use a simple, zero dependencies installer for erlang.
There is a great project on Github from the guys at RabbitMQ - erlang-rpm, but this is RPM only.
I'm aware of erlang-solutions, but it not a single, no dependencies installer.
EDIT: Adding some context here. I need this to be able to prepare a simple, offline install to my app, which needs RabbitMQ. Offline means NO access to internet for downloading dependencies.
Any ideas?
There is no Zero-dependency Erlang Ubuntu/Debian for RabbitMQ.
But the Erlang Solution package can be installed easily.
We built the Centos package because the dependencies are hard to install on Centos (if you don't want to use the epel)
If you want to create an offline setup, you can do it like for other packages (https://askubuntu.com/questions/974/how-can-i-install-software-or-packages-without-internet-offline). Or you can create your own package by building Erlang from source code.
Note also RabbitMQ has dependencies as socat
I use Vagrant + virtualBox and a Debian 8 / Ubuntu image for my development environments.
I want to use nix for provisioning, but I can't get nixOS to work completely right (ie. with networking, provisioning...), but I'd more than happy to switch. So I'm falling back to nix + Debian 8 or nix + Ubuntu to mimic the production server.
I can't quite get the differences between user packages and system packages and what is preferable to use in in my context, in order to be able to reuse that into a production server.
Should I install packages with nix -i, or edit the configuration.nix file ?
Whether you should install packages into the system profile or into a user profile depends on what you'd like to achieve. There is no single right answer. Instead, both types of installing packages have different pros and cons.
System packages are defined in a global configuration file that typically resides in /etc/nixos/configuration.nix. Users other than root can typically not edit that file and thus cannot add or remove packages from the list. Packages defined in there will be installed as part of nixos-rebuild and they'll be available in $PATH to every user of your system. If any of those packages don't compile for some reason, however, then you cannot rebuild your system, i.e. you may find yourself in a situation where you cannot update your kernel because, say, nano doesn't compile. People who follow the master branch of the Nixpkgs git repository may experience this problem frequently, but it doesn't happen so much for users of the unstable or the release-x.y channels.
User packages can be installed, updated, and de-installed by any user on your system without the need for super-user privileges. One user's packages will not be visible to another user (unless she makes a conscious effort to import them into $PATH). Thus, it's possible for two users to install two different versions of the same package.
If a user does not regularly update her profile, then you'll accumulate old packages in your Nix store that cannot be garbage collected. This may be a problem or a feature, depending on how you look at it. System packages, on the other hand, are all updated every time you update the system, so those tend to have a smaller disk space footprint.
Personally, I prefer to keep my system profile as small as possible; I install packages mostly into user profiles with nix-env. I know many people, however, who do the exact opposite and we all get along fine. :-)
I have Python 2.7 installed in "C:\Python27". Now I run 1st demo of Python4delphi with D7, which somehow uses my Py2.7 install folder. If I rename Python folder, demo can't run (without error message). I didn't change properties of a demo form.
What part/file does py4delphi use from my Python folder?
python4delphi is a loose wrapper around the Python API and as such relies on a functioning Python installation. Typically on Windows this comprises at least the following:
The main Python directory. On your system this is C:\Python27.
The Python DLL which is python27.dll and lives in your system directory.
Registry settings that indicate where your Python directory is installed.
When you rename the Python directory, the registry settings refer to a location that no longer exists. And so the failure you observe is entirely to be expected.
Perhaps you are trying to work out how to deploy your application in a self-contained way without requiring an external dependency on a Python installation. If so, then I suggest you look in to one of the portable Python distributions. You may need to adapt python4delphi a little to find the Python DLL which will be located under your application's directory. But that should be all that's needed. Take care of the licensing issues too if you do distribute Python with your application.