Hi I only have a little linux knowledge,Im afraid . Is there an efficient way to transfer all apps from fedora34 to fedora 36? using dom0 terminal if possible, it seems stupid to have to re download 50apps one by one. I have searched the Documentation but cannot find anything that adresses this particular problem.
The best option is to just script the installation process, so that you can re-run that script when you install a new template. You may also want to consider if you truly need 50 apps in a single template, which can increase the risk considerably. Perhaps you really want a few templates with some of the needed apps in each and then create the appropriate appVM from the corresponding template.
But if the issue is to do this too frequently, due to the relatively short Fedora life term, you may want to consider using Debian templates instead. Stable Debian versions last for years, as opposed to the 6 months in Fedora (or 12 months, if you go all the way skipping one Fedora release at a time).
Hi thanks for your reply
how do i do that? I am very old sorry.
I thought if i put them in the main fedora template with no internet acess, exept for the initial downloads they would be safe? I then use 5-6 apps in each of the other child qubes if that is the correct expression. You seem to be saying this is not too secure though. worryingly.
Installing packages in Linux is usually just one line of shell script. Something like āsudo dnf install pkg1 pkg2 pkg3ā. Just save that line and use it every time you install a new template.
The problem with installed software in your template is that all VMs that use that template will have that software installed too. This can increase the exposure to a certain degree since any vulnerability in any of those packages could potentially be leveraged by an attacker compromising that VM (for example, if one of those packages has a vulnerable component that allows for escalation of privilege). It all depends on your risk tolerance, of course. If, for example, you want a qube that will run LibreOffice and also needs a PDF viewer and drawing tool, you could clone a template, add those to the clone and create a qube based on that new template. If you also want a different qube to run your email client, a web browser and a music player, you can clone that general template again, add these three to the clone and create a qube based on that clone.
Itās probably not a good idea to have hundreds of templates, but having just one with a ton of apps installed is not that good either. You need to see where you strike that balance. The disadvantage of multiple templates is that they need to be backed up and patched independently and they can increase the overall disk utilization. The benefit is that they reduce the blast radius.
Thanks very much. I will take your advise, I hadnt realised
the other vmās would all be running all the apps even the ones that i hadnāt transported over in the app (activator- transfer) columns.
this is where I am a bit lost because I have been using the fedora 34 software GUI and I think you are refering to a terminal type package installer I remember using in manjaro I think it was called dnf something or other Pacman maybe. Is their somthing similar in fedora terminal with a list of apps perhaps?
Oh, I see! You really canāt script the gui version, but if you open a terminal for that template, you can use the command:
sudo dnf install package_name_1 package_name_2 etc
So, you can check the list of things that you need in the GUI package manager and then use the terminal. And if you safe that line, you can use it again when you install the next version of the template.
1 Like
Brilliant I will try that thanks very much Flavio, You have been a great help. Cheers.
1 Like
If you have many templates, then using a caching proxy in place of the
standard proxy is a real help. It reduces the overhead on downloads, and
speeds the process a good deal.
This has been discussed on the forum before.
I use salt to document my downloads:
# vim: set syntax=yaml ts=2 sw=2 sts=2 et :
{% if salt['qvm.exists']('cacher') %}
/etc/yum.repos.d/:
file.replace:
- names:
- /etc/yum.repos.d/fedora.repo
- /etc/yum.repos.d/fedora-updates.repo
- /etc/yum.repos.d/fedora-updates-testing.repo
- /etc/yum.repos.d/fedora-cisco-openh264.repo
- pattern: 'metalink=https://(.*)basearch'
- repl: 'metalink=http://HTTPS///\1basearch&protocol=http'
- flags: [ 'IGNORECASE', 'MULTILINE' ]
/etc/yum.repos.d/qubes-r4.repo:
file.replace:
- pattern: 'https://'
- repl: 'http://HTTPS///'
- flags: [ 'IGNORECASE', 'MULTILINE' ]
{% endif %}
install:
pkg.installed:
- pkgs:
- qubes-core-agent-networking
- qubes-core-agent-passwordless-root
- qubes-gpg-split
- aspell
- aspell-en
- createrepo_c
- createrepo_c-libs
- debootstrap
- devscripts
- dialog
- dpkg-dev
- fedora-packager
- fedora-review
- g++
- gcc
- git
- gitg
- gnupg
- m4
- make
- perl-Digest-MD5
- perl-Digest-SHA
- python3-pyyaml
- python3-sh
- re2c
- reprepro
- rpm-build
- rpm-sign
- rpmdevtools
- systemd-container
- texinfo
- wget
- zlib-devel
This is part of a formula for a build machine - the heavy lifting is done by the
pkg.installed section.
Salt allows you to use pkg.installed: when you apply it the
appropriate package handler (dnf,apt,pacman) will be used.
I find this simpler and easier to maintain than a shell script.
Of course, this will be no use to you if you havenāt already done this.
In that case you can get a list of installed software like this:
rpm -qa --last - will list installed packages by date of installation.
More useful would be:
repoquery --qf '{name}' --userinstalled > pkgs_list.
Copy the pkgs_list file to the other template.
cat pkgs_list |xargs dnf -y install
On a Debian template, you can use dpkg --get-selections in one
template, and then dpkg --set-selections in the other.
But instead of doing this, take this opportunity to salt the install.
Itās a self documenting approach that will help in this sort of case.
When I comment in the Forum or in the mailing lists I speak for myself.
1 Like
Thanks unman or has flavio dropped this in? I will try to work out how to use salt but I am not familiar enough with terminal yet
If I pasted that into terminal what would happen? That is unfortunately my knowlege of it at the moment.
What is the best book or tutorial to get myself by, in terminal I would love to get the hang of it it seems so usefull, but scary?
I will attempt to do it but will probably fail a few hundred times first.
Why do you want to transfer apps between those fedora versions? Is in place upgrade not a viable option for you?
1 Like
The directions advise against inexpierienced users trying that method it says only recomended for advanced users.
I assumed that there are other security needs benefits etc from going up two levels. But Ivāe read elswhere that updating is just the same as upgrading. Hence my need of expert advice. Thanks.
Also flavio has suggested that Keeping so many apps in one basket is high risk. I have counted 99 which i thought were safe as they werenāt deployed but that isnāt the case apparently.
It says āadvancedā for some reason but itās 2 commands to use so I donāt think you will encounter any problems since itās the normal Fedora upgrade process.
If you want to try without losing anything, clone the targeted template to something like āfedora-35-upgradeā (upgrade to 35 first, not 36 directly), start the template and in a terminal do the following commands:
sudo dnf clean all
sudo dnf --releasever=35 distro-sync --best --allowerasing
Note: It will ask you to validate keys, so keep an eye on the upgrade
It will take some time, especially if using Tor on templates. Once itās done, reboot the template, check that some of the apps works correctly and then do the same commands but replace ā35ā by ā36ā.
Last step is to rename the template to āFedora-36ā (or any name you would like).
1 Like
yes this worked very well it took three hours net time though 7 hours my time But got the job mostly done .
I just cant get, remember how to make fedora 36 the main disposable template it wont allow me in advanced fed 36 settings. Saying,
ERROR: Advanced tab:
invalid property ātemplate_for_dispvmsā of fedora-36
Fed-34 is the original install template. i will put solved as soon as I manage to get 36 to run as the disposable dvm.
You should be able to do that in āQubes Global Settingsā.
Edit: If you want to create a DisposableVM for Fedora-36, you have to create a new AppVM based on that template and add the āDisposable templateā option in the āAdvancedā tab inside the VM settings.
Hi global settings will only show fedora34-dvm
or whonix-ws-16-dvm (no fed36-dvm option)
will try this.
Nothing would happen, but error messages.
Salt states are simple text files that describe how you want your system
to be.
You apply them in Qubes using the qubesctl command, like this:
qubesctl --skip-dom0 --targets=TARGET_QUBE state.apply build.install
where build.install identifies the state file.
Thereās a basic introduction to the use of salt in Qubes, with plenty of
examples, at GitHub - unman/notes
Thanks unman i will try that later. But my problem still remains Ivāe updated 36 but cannot get it to show as diposable template in global settings therfore cannot get 36 to show as an option for default disp-dvm in qube manager ,it will only show fed-34
I have tried to clone 36 and set it as default in advanced settings but just get an error message
invalid property "template_for _dispvms"of fedora-36clone-1
The same happens for the original fed-36 maybe ive misunderstood App VM for cloning I dont know.
disposables are based on a disposable template, which is then based on a
template.
So you have to create a Template based qube, and set the property:
qvm-prefs QUBE template_for_dispvms True
If you have done an in place upgrade to fedora36, then you can simply
clone fedora-34-dvm to fedora-36-dvm, and make sure the template for
that qube is set to the fedora-36 template.
When I comment in the Forum or in the mailing lists I speak for myself.
Thanks that is the part ididnt have.
Well done for sticking at it and getting there.
Youāve learnt a good deal about a basic part of Qubes.