I'm learning to use multipass. My version of multipass is multipass 1.9.0+mac. I'm trying to create a very simple cloud-init configuration:
package:
- build-essential
- zsh
I start this with
multipass launch -n test --cloud-init config.yaml
I open a shell into that environment, but there is no zsh in /bin/.
Why was zsh not installed?
package is not a valid top-level key, but packages is. See the docs here.
It really should warn for this error but does not currently.
Try this:
#cloud-config
packages:
- build-essential
- zsh
Upstream cloud-init is working on better warnings/errors for this using jsonschema validation for configs (many changes on this front in upcoming releases). Currently, however, top level keys are not validated currently.
Also, it looks like multipass automatically inserts the #cloud-config header for you so I don't think you need it on multipass specifically, but for portability to other datasources I would consider adding it anyways. Based on the userdata values in a multipass instance I tested I see the header both ways, so for portability I recommend adding it even though it's a no-op on multipass.
Also per Brett's comment https://stackoverflow.com/a/72233577/8479562, sudo cloud-init devel schema --annotate --system should report whether the #cloud-config provided is was valid schema or not.
Related
pandoc-crossref must match the pandoc version, and also only the 3.10.0 release works on OSX Big Sur. Thus, it is not possible to get pandoc and pandoc-crossref running in a conda environment from the official channel or from conda-forge.
I could easily download the matching binaries from https://github.com/lierdakil/pandoc-crossref/releases/tag/v0.3.10.0 and copy them e.g. to the binpath:
$ which pandoc-crossref
/usr/local/bin/pandoc-crossref
$ curl -OL https://github.com/lierdakil/pandoc-crossref/releases/download/v0.3.10.0/pandoc-crossref-macOS.tar.xz
$ tar -xzvf pandoc-crossref-macOS.tar.xz
$ mv pandoc-crossref /usr/local/bin/pandoc-crossref
But I think that is not a clean approach, because conda will not know that I updated the version for pandoc-crossref.
What is a clean approach for updating a package managed by conda from a binary available on Github?
Update Feedstock
I updated it on the Conda Forge feedstock, which is what I regard as the "cleanest" solution.
How does one do that? First, OP had posted a comment on the feedstock in the PR that they wanted merged. This was the appropriate first step and hopefully in future cases that should be sufficient to prompt maintainers to act. In this case, it was not sufficient. So, as a follow up, I chatted on the Conda Forge Gitter to point out that the feedstock had gone stale and had non-responding maintainer(s). One of the core Conda Forge members suggested I make a PR bumping the version and adding myself as maintainer, and they merged it for me. In all, this took about 10 mins of work and ~2 hours from start to having an updated package on Anaconda Cloud.
Custom Conda Build
Otherwise, there isn't really a clean solution for non-Python packages outside of building a Conda package. That is, clone the feedstock or write a new recipe, modify it to build from the GitHub reference, then install that build into your environment. It may also be worth uploading to an Anaconda Cloud user account, so there is some non-local reference for it.
Pip Install (Python Packages Only)
In the special case that it is a Python package, one could dump the environment to YAML, edit to install the package through pip, then recreate the environment.
I'm trying to use VSCode Remote extension to connect to a remote host that runs on RHEL/CentOS 6, but it fails to connect since CentOS 6 ships with GLIBC 2.12 and GLIBCXX 3.4.1. As mentioned in this post, in order to get the extension to work, the workaround is to install GLIBC>=2.17 and GLIBCXX>=3.4.18.
Unfortunately, I don't have sudo access for the server, so I won't be able to update these libraries using the bash script provided in the link. Also, in this SO post, the author says not to update the system GLIBC since it can break down system applications. That being said, I've tried something different -- I extracted those rpm packages, as described in this blog, inside my home folder. I've then updated the env variables PATH and LD_LIBRARY_PATH in ~/.bash_profile to point to these new locations. But the node binary (in VS Code Remote) still can't find these libraries.
Is there a way to let the node binary know where to look for these libraries? More precisely, can someone explain how I can make this extension work without sudo access?
I've got it to work by installing gcc and glibc using Linuxbrew. See this post for more details: https://github.com/microsoft/vscode-remote-release/issues/103#issuecomment-546551293.
Couple of things to take note of:
Node binary versions in VS Code Server may vary between commits. In the GitHub comment above, the author uses node#10 -- you may replace it with node#12; everything would still work.
Make sure glibc and gcc are properly installed using linuxbrew. This step is key.
I have a data ware house running on PostgreSQL and I would like to check what all are the missing indices are in my database.
I tried to install the extension pg_qualstats but it is giving the below error.
root#Ubuntu-1604-xenial-64-minimal ~ # sudo pip install pg_qualstats
Collecting pg_qualstats
Could not find a version that satisfies the requirement pg_qualstats (from versions: )
No matching distribution found for pg_qualstats
You are using pip version 18.1, however version 19.2.3 is available.
You should consider upgrading via the 'pip install --upgrade pip' command.
root#Ubuntu-1604-xenial-64-minimal ~ #
So how can i install this extension? I tried the CREATE EXTENSION pg_qualstats but it was giving error.
Also is there any other database maintenance need to be done for the database regularly?
What all parameter I have to check?
Can we automate the maintenance activity?
I was a SQL server DB admin and it was much easier to find out the missing index, understand the execution plan, DB maintenance but I find it hard, when it comes to PostgreSQL.
So any guidance will be of great help.
I am only answering the immediate question regarding the installation of pg_qualstats - the rest of the questions are way too broad for a platform like stackoverflow (or dba.stackexchange).
Many interesting extensions are provided as source code in Postgres (that's one of the reasons why it's highly recommended to run Postgres on Linux, because compiling the extensions is way easier in Linux than it is on Windows, and may extensions are only developed for Linux).
pg_qualstats is no different.
It is provided together with PoWA and the installation of the extension is documented as part of their installation guide
In a nutshell:
Download the source:
wget https://github.com/powa-team/pg_qualstats/archive/1.0.7.tar.gz -O pg_qualstats-1.0.7.tar.gz
tar zxvf pg_qualstats-1.0.7.tar.gz
cd pg_qualstats-1.0.7
the compile it:
make
make install
Register the shared libraries by editing postgresql.conf and after restarting Postgres the extension can be created using CREATE EXTENSION pg_qualstats;
I've been using stylelint-gulp for some time now without issue.
I have stylelint loaded as a npm devDependancy(ie not global, as I dont want it to be global) in my project, and following the instructions I should have the CLI available as well.
however stylelint --help returns "command not found"
I have other modules installed like eslint, and the cli works just fine.
node: v12.11.1
npm: 6.11.3
I also have nvm installed so I've tried switching back to npm --lts but it's still not working. Btw, this is on osx 10.13.6 if it matters.
any advice?
As you don't have stylelint installed globally you won't have the stylelint command available globally.
Similar to noted in the comment above, the best way to use the stylelint command when you don't have it installed globally is to access it via a repo where you do have it installed:
./node_modules/.bin/stylelint "**/*.css"
The short answer:
With any locally installed npm package (ie as a project's devDependancy), you should not expect to be able to run the package's CLI as follows <package_name> --help. You will need to include the full path to the module in the .node_moduels/ directory, just as #netweb has shown in his answer:
./node_modules/.bin/stylelint --help
IMHO Stylelint's documentation page is a tad confusing in this regard, which is why I asked the question.
The longer answer:
To be able to run stylelint --help or any other npm CLI, you would have to† install the package globally, ie: <package_name> -global. In that process, a symlink is created so the <package_name> keyword could be invoked in any directory on the system.
However, there is a category of tools (for example linters) where its usually considered bad practice to install them globally. This is because different projects will likely have conflicting requirements, in which case, having all these tools globally installed quickly becomes problematic. It's best to have these tools installed at the project level as a devDependancy like so: npm install <package_name> --save-dev.
If you are setting up an npm scripts or Continuous Integration systems then you would invoke these tools' CLI by including the path to the local install: ./node_modules/.bin/stylelint "**/*.css"
However, in the terminal, writing the fill path each and every time you want to invoke a tool is painful, so instead, you can use [npx][4] to invoke the locally installed module:
npx stylelint --help
† npm-link, also symlinks your local package as if it was a globally installed. However, except for some specific scenarios, it's very unlikely you want to make globally available a local devDependancy.
I have built a RPM-package for Centos 6.6 that is installed on a machine of our customer.
This package contains our own software, customized for the specific use case, but also uses the open-source package HAProxy.
HAProxy (RPM-version 1.5.4-2.el6_7.1) comes with a default-configuration in /etc/haproxy/haproxy.conf and it cannot be customized without changing this file.
But I want the configuration to be part my generated package. RPM throws an error if the /etc/haproxy/haproxy.conf file is in my package, because it is also part of the haproxy-package.
I have worked around this problem by providing a custom upstart-script which starts HAProxy with a different config file, but this does not seem to be the right way to do this.
Is there a preferred way to handle such customizations?
In cases like this, I've created an RPM which installs configuration files into a different subdirectory, and in its %post and %preun scriptlets modifies the uncooperative package's config-files:
when installing, I renamed the original config-files, and made symbolic links from those pathnames to the overwriting config-files, and
when uninstalling, the package removed the symbolic links and restored the original package's files.
Doing it that way of course meant that my config-RPM was dependent on the original RPM. A little awkward to describe, but it works.
In followup, the issue of updating was mentioned. Updating an RPM requires special handling to avoid uninstalling things. The rpm program passes a parameter $1 which you can test in the %pre and %preun scriptlets to notice that this is an upgrade and that there is no need to save the original config-files (or restore them). The rest of the scriptlet would be the same, by copying the new versions of your config-files over the others.
Further reading:
Defining installation scripts (shows the use of `$1)
RPM upgrade uninstalls the RPM
Your approach is correct. On EL6 and sysv there is no other choice than creating custom haproxy package or custom haproxy service or create script which customer runs after installation. I see creating another service as best option.
Note that on EL7 with SystemD you have much better option as you can use Drop-In feature of SystemD. For more information see:
https://coreos.com/os/docs/latest/using-systemd-drop-in-units.html
https://wiki.archlinux.org/index.php/systemd#Drop-in_snippets
https://wiki.archlinux.org/index.php/Systemd/User#Service_example
The usual way this is done is to have a drop-in configuration directory, e.g. /etc/httpd/conf.d/, where your package would drop its configuration, and you would tell the other daemon, e.g. httpd, to do a graceful restart in your %post/%postun.
I don't know anything about HAProxy, but a quick search implies that they do not support this configuration directory concept that has been around for many years. A few people have hacked it in, but unless it is out-of-the-box, you will run into your original problem again.