Thanks for investigating. That’s pretty great! The dependencies are automatically sorted out.
But the debian one above failed.
I’ll look into this over the next days and update the guide accordingly
Thanks for investigating. That’s pretty great! The dependencies are automatically sorted out.
But the debian one above failed.
I’ll look into this over the next days and update the guide accordingly
The problem I’ve been having with running Local WP in App VMs are these error when I try to link my site to their server:
My Local WP was installed in a Template VM.
I see. So here the issue is very specific. For some reason that library was not present in the dependencies list. See this:
You’ll have to install the package in debian or fedora that includes the libnuma.so.1
library. I generally do this by looking up the library’s name and then the distrubution. For example libnuma.so.1 fedora
.
Thanks.
That’s a pretty awesome guide! I would have liked many times to have this information. What about providing a link to it, possibly in the official documentaion in Installing and updating software in domUs ?
Thanks for the suggestion! I think that would be a nice idea. I think that documentation page needs a lot of improving on alternative installation methods.
But first I’ll have move this to the community documentation, probably. (or see if it’s appropriate to go on the official docs). I’ll see if I can get around to doing ths.
This is not necessarily a failure.
When executing sudo apt install [package]
, apt drops privileges to the _apt
user while downloading the file, usually from a remote mirror.
As apt
is being told to download a package within file:///home/user/…, it is unable to access as /home/user blocks all permissions except owner. It is non-fatal and only a warning.
apt
is informing that it didn’t drop privileges to retrieve the file, which is typically good security practice (apt doesn’t need to be root to download a file, but it does need to be root to install it). If the package file is in a directory accessible by the user _apt
, the message will go away.
As
apt
is being told to download a package within file:///home/user/…, it is unable to access as /home/user blocks all permissions except owner. It is non-fatal and only a warning.
so you are saying that the installation is successful even with said warning?
Correct, the “local” package did get installed…apt is just warning how it retrieved the package file.
Get:2 /home/user/local-5.9.9-linux.deb local amd64 5.9.9-20210215.1 [150 MB]
...
Fetched 1,287 kB in 3s (410 kB/s)
...
Selecting previously unselected package local.
Preparing to unpack .../user/local-5.9.9-linux.deb ...
Unpacking local (5.9.9-20210215.1) ...
...
Setting up local (5.9.9-20210215.1) ...
@rooftop also shared a similar answer:
The message is because the user _apt can’t access the .deb file as the parent directory /home/user is only accessible by the user user. If you were to copy the .deb file to /tmp (for example) and install it from there you would not get the message. However, I believe the package should have installed correctly even with the warning message. Did you try running it?
sudo dnf install ~/QubesIncoming/disp3741/local-5.9.9-linux.rpm
I think the latest Qubes Security Bullentin breaks this. So the guide will have to be tested / updated:
- requested to do so. This breaks use cases such as installing
- locally-built packages and installing manually-downloaded packages the
- integrity of which was verified separately (which is often the case for
- closed-source software).
- In such cases, neither `dnf install /path/to/the/package.rpm` nor `rpm
- -i /path/to/the/package.rpm` will work any longer. Instead, to install a
- package without a trusted signature (that has been verified by other
- means), use the following command:
- rpm --define '_pkgverify_level digest' -i /path/to/the/package.rpm
- If the package has any dependencies, the above command will list them,
- and they will have to be installed with `dnf` manually.
- Credits
- ========
- These issues were discovered and reported by Demi M. Obenour.
Indeed. It looks like the guide needs to be reverted to one that explains installation using rpm.
[user@disp4093 ~]$ sudo dnf install ./local-5.10.1-linux.rpm
Warning: Enforcing GPG signature check globally as per active RPM security policy (see 'gpgcheck' in dnf.conf(5) for how to squelch this message)
Last metadata expiration check: 0:00:09 ago on Sat Mar 20 17:50:43 2021.
Dependencies resolved.
================================================================================
Package Arch Version Repository Size
================================================================================
Installing:
local x86_64 5.10.1-20210305.4 @commandline 142 M
Installing dependencies:
ncurses-compat-libs x86_64 6.2-3.20200222.fc33 fedora 326 k
nss-tools x86_64 3.62.0-1.fc33 updates 531 k
Transaction Summary
================================================================================
Install 3 Packages
Total size: 143 M
Total download size: 857 k
Installed size: 816 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): nss-tools-3.62.0-1.fc33.x86_64.rpm 230 kB/s | 531 kB 00:02
(2/2): ncurses-compat-libs-6.2-3.20200222.fc33. 140 kB/s | 326 kB 00:02
--------------------------------------------------------------------------------
Total 203 kB/s | 857 kB 00:04
Package local-5.10.1-linux.rpm is not signed
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: GPG check FAILED
[user@disp4093 ~]$
Thanks for testing. I’ve now reverted the instructions on the fedora part and added the parameter to allow installing unsigned packages. Additionally I’ve also added disclaimer explaining the reasoning behind the security workaround and a pointer to the Qubes Security Bulletin.
The debian ones are still the same (easy ones) you suggested.
6. Update it!
Now, because you installed it manually, whenever there is an update for this application you’ll have to remember to update it by repeating this exact process with the new version.
You’ll remember to do this, right?!
To update it, do I need to remove the currently installed .deb or just install the new .deb while leaving the last .deb installed?
To update it, do I need to remove the currently installed .deb or just install the new .deb while leaving the last .deb installed?
You shouldn’t need to uninstall the package (or remove the .deb
file from wherever you downlodaded it) @adamrichards.
When installing the more recent version, you should see confirmation in the output of the apt
command that the packaged was updated from the previous to the new version. They are different versions of the same package after all, and apt
is able to detect that.
This is more or less what I’ve ended up doing. Good to know I’ve found a good way. The way I think about it, once I’m in the standalone I just treat it like it’s a normal Linux system.
This was very concise. I wish I’d found this when I first started using Qubes. Guess I should have looked through the forum more, lol.
It took me a few days of pain to figure out how to install some of the proprietary and non-repo stuff I need to run.
It is also possible to do it on TemplateVMs but that is a bit more involved – let’s leave that as homework.
You mention that there is a different method for doing a deb install on template VMs, but you never followed up with the “homework” and explained how to do this in templates. The problem with standalone VM’s is you can’t update them securely I dont think.
Can you please explain how to do this in template VM’s?
The problem with a self
Oh. The homework for the readers.
The same exact thing can be done in Template VMs. The only difference really is that you install in the template but don’t run it there.
The reason why I suggested installing it in a standalone is because often times these debs are not verified and may contain untrusted components (not to mention outdated software). The it’s prone to becoming outdated ( you have to install the new deb to keep it up to date), which is bad security-wise. And if it’s something that runs at the system startup, you may end up exposing all your VMs based on the template.
So I generally would do this in a standalone but in the template it’s also fine as long as you understand the risks.