Qubes/core-admin
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
3db5e9f8bf
core-admin/Makefile

247 lines
7.8 KiB
Makefile
Raw Normal View History

Initial public commit. (c) 2010 Invisible Things Lab Authors: ========= Joanna Rutkowska <joanna@invisiblethingslab.com> Rafal Wojtczuk <rafal@invisiblethingslab.com>
2010-04-05 20:58:57 +02:00
RPMS_DIR=rpm/
Makefile improvements for repo management * Sign only current version of the rpms generated * repo-update-{current,unstable} targets for new yum repo
2011-04-04 10:55:25 +02:00
Rename 'version_dom0' -> 'version' This repository contains only dom0 files now.
2013-03-12 16:50:14 +01:00
VERSION := $(shell cat version)
Makefile improvements for repo management * Sign only current version of the rpms generated * repo-update-{current,unstable} targets for new yum repo
2011-04-04 10:55:25 +02:00
Makefile: use fc18 as default value for DIST_DOM0
2013-02-28 14:43:32 +01:00
DIST_DOM0 ?= fc18
makefile: support dom0 different than fc13
2013-01-25 03:07:16 +01:00
makefile: install only relevant stuff according to OS/VMM
2013-07-22 04:18:19 +02:00
OS ?= Linux
fix Makefile, setup.py, spec and travis QubesOS/qubes-issues#2074
2017-01-20 12:40:00 +01:00
PYTHON ?= python3
makefile: install only relevant stuff according to OS/VMM
2013-07-22 04:18:19 +02:00
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
ADMIN_API_METHODS_SIMPLE = \
admin: add admin.deviceclass.List QubesOS/qubes-issues#5213
2019-08-06 10:07:14 +02:00
admin.deviceclass.List \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.vmclass.List \
admin.Events \
admin.backup.Execute \
admin.backup.Info \
api/admin: plug backup into Admin API Fixes QubesOS/qubes-issues#2931
2017-07-20 03:07:46 +02:00
admin.backup.Cancel \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.label.Create \
admin.label.Get \
admin.label.List \
Generate policy for Admin API calls based on annotations on actual methods This ease Admin API administration, and also adds checking if qrexec policy + scripts matches actual Admin API methods implementation. The idea is to classify every Admin API method as either local read-only, local read-write, global read-only or global read-write. Where local/global means affecting a single VM, or the whole system. See QubesOS/qubes-issues#2871 for details. Fixes QubesOS/qubes-issues#2871
2017-06-27 01:55:17 +02:00
admin.label.Index \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.label.Remove \
admin.pool.Add \
admin.pool.Info \
Added admin.pool.UsageDetails API method admin.pool.UsageDetails reports the usage data, unlike admin.pool.Info, which should report the config/unchangeable data. At the moment admin.Pool.Info still reports usage, to maintain compatibility, but once all relevant tools are updated, it should just return configuration data.
2019-10-22 21:42:36 +02:00
admin.pool.UsageDetails \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.pool.List \
admin.pool.ListDrivers \
admin.pool.Remove \
api/admin: add API for changing revisions_to_keep dynamically This one pool/volume property makes sense to change dynamically. There may be more such properties, but lets be on the safe side and take whitelist approach - allow only selected (just one for now), instead of blacklisting any harmful ones. QubesOS/qubes-issues#3256
2017-11-07 02:34:43 +01:00
admin.pool.Set.revisions_to_keep \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.pool.volume.Info \
admin.pool.volume.List \
admin.pool.volume.ListSnapshots \
admin.pool.volume.Resize \
admin.pool.volume.Revert \
api/admin: add API for changing revisions_to_keep dynamically This one pool/volume property makes sense to change dynamically. There may be more such properties, but lets be on the safe side and take whitelist approach - allow only selected (just one for now), instead of blacklisting any harmful ones. QubesOS/qubes-issues#3256
2017-11-07 02:34:43 +01:00
admin.pool.volume.Set.revisions_to_keep \
api/admin: implement admin.vm.volume.Set.rw method Allow setting 'rw' volume property.
2018-03-18 23:07:40 +01:00
admin.pool.volume.Set.rw \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.pool.volume.Snapshot \
admin.property.Get \
api/admin: implement *.property.GetAll methods Allow getting all the VM properties with one call. This greatly improve performance of an applications retrieving many/all of them (qvm-ls, qubes manager etc) QubesOS/qubes-issues#5415 Fixes QubesOS/qubes-issues#3293
2019-12-03 06:27:37 +01:00
admin.property.GetAll \
admin-api: add admin.*.property.GetDefault Fixes QubesOS/qubes-issues#3197
2017-10-20 01:37:20 +02:00
admin.property.GetDefault \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.property.Help \
admin.property.HelpRst \
admin.property.List \
admin.property.Reset \
admin.property.Set \
admin.vm.Create.AppVM \
admin.vm.Create.DispVM \
admin.vm.Create.StandaloneVM \
admin.vm.Create.TemplateVM \
admin.vm.CreateInPool.AppVM \
admin.vm.CreateInPool.DispVM \
admin.vm.CreateInPool.StandaloneVM \
admin.vm.CreateInPool.TemplateVM \
api/admin: add admin.vm.CreateDisposable in place of internal.vm.Create.DispVM Add public Admin API call to create Disposable VM that would be automatically destroyed after shutdown. Do not keep this functionality for qrexec-policy tool only. Also, use admin.vm.Start there, instead of internal.vm.Start and admin.vm.Kill instead of internal.vm.CleanupDispVM (this is enough, because DispVM now have auto_cleanup property). QubesOS/qubes-issues#2974
2017-08-06 12:35:35 +02:00
admin.vm.CreateDisposable \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.vm.Kill \
admin.vm.List \
admin.vm.Pause \
admin.vm.Remove \
admin.vm.Shutdown \
admin.vm.Start \
admin.vm.Unpause \
admin.vm.device.pci.Attach \
admin.vm.device.pci.Available \
admin.vm.device.pci.Detach \
admin.vm.device.pci.List \
api/admin: implement admin.vm.device....Set.persistent This will allow converting persistent device (used to boot VM for example) to non-persistent. QubesOS/qubes-issues#3055
2017-09-02 17:59:29 +02:00
admin.vm.device.pci.Set.persistent \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.vm.device.block.Attach \
admin.vm.device.block.Available \
admin.vm.device.block.Detach \
admin.vm.device.block.List \
api/admin: implement admin.vm.device....Set.persistent This will allow converting persistent device (used to boot VM for example) to non-persistent. QubesOS/qubes-issues#3055
2017-09-02 17:59:29 +02:00
admin.vm.device.block.Set.persistent \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.vm.device.mic.Attach \
admin.vm.device.mic.Available \
admin.vm.device.mic.Detach \
admin.vm.device.mic.List \
api/admin: implement admin.vm.device....Set.persistent This will allow converting persistent device (used to boot VM for example) to non-persistent. QubesOS/qubes-issues#3055
2017-09-02 17:59:29 +02:00
admin.vm.device.mic.Set.persistent \
features: add check_with_netvm, similar to check_with_template Allow using default feature value from netvm, not template. This makes sense for network-related features like using tor, supporting ipv6 etc. Similarly to check_with_template, expose it also on Admin API.
2017-12-01 03:19:48 +01:00
admin.vm.feature.CheckWithNetvm \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.vm.feature.CheckWithTemplate \
qubes/features: check_with_(template_and_)adminvm - Two new methods: .features.check_with_adminvm() and .check_with_template_and_adminvm(). Common code refactored. - Two new AdminAPI calls to take advantage of the methods: - admin.vm.feature.CheckWithAdminVM - admin.vm.feature.CheckWithTemplateAndAdminVM - Features manager moved to separate module in anticipation of features on app object in R5.0. The attribute Features.vm renamed to Features.subject. - Documentation, tests.
2018-11-15 16:59:00 +01:00
admin.vm.feature.CheckWithAdminVM \
admin.vm.feature.CheckWithTemplateAndAdminVM \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.vm.feature.Get \
admin.vm.feature.List \
admin.vm.feature.Remove \
admin.vm.feature.Set \
admin.vm.firewall.Flush \
admin.vm.firewall.Get \
admin.vm.firewall.Set \
admin.vm.firewall.GetPolicy \
admin.vm.firewall.SetPolicy \
admin.vm.firewall.Reload \
admin.vm.property.Get \
api/admin: implement *.property.GetAll methods Allow getting all the VM properties with one call. This greatly improve performance of an applications retrieving many/all of them (qvm-ls, qubes manager etc) QubesOS/qubes-issues#5415 Fixes QubesOS/qubes-issues#3293
2019-12-03 06:27:37 +01:00
admin.vm.property.GetAll \
admin-api: add admin.*.property.GetDefault Fixes QubesOS/qubes-issues#3197
2017-10-20 01:37:20 +02:00
admin.vm.property.GetDefault \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.vm.property.Help \
admin.vm.property.HelpRst \
admin.vm.property.List \
admin.vm.property.Reset \
admin.vm.property.Set \
admin.vm.tag.Get \
admin.vm.tag.List \
admin.vm.tag.Remove \
admin.vm.tag.Set \
Merge remote-tracking branch 'origin/policy-adminvm'
2017-07-04 14:51:51 +02:00
admin.vm.volume.CloneFrom \
admin.vm.volume.CloneTo \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
admin.vm.volume.Info \
admin.vm.volume.List \
admin.vm.volume.ListSnapshots \
admin.vm.volume.Resize \
admin.vm.volume.Revert \
api/admin: add API for changing revisions_to_keep dynamically This one pool/volume property makes sense to change dynamically. There may be more such properties, but lets be on the safe side and take whitelist approach - allow only selected (just one for now), instead of blacklisting any harmful ones. QubesOS/qubes-issues#3256
2017-11-07 02:34:43 +01:00
admin.vm.volume.Set.revisions_to_keep \
api/admin: implement admin.vm.volume.Set.rw method Allow setting 'rw' volume property.
2018-03-18 23:07:40 +01:00
admin.vm.volume.Set.rw \
api/admin: implement admin.vm.Stats QubesOS/qubes-issues#853
2017-07-27 22:20:12 +02:00
admin.vm.Stats \
Add admin.vm.CurrentState method For all the transient values that should not be treated as real properties. To be used in core-admin-client.
2020-01-15 15:56:31 +01:00
admin.vm.CurrentState \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
$(null)
makefile/windows: use c:\qubes as default data dir
2013-07-30 10:44:20 +02:00
ifeq ($(OS),Linux)
DATADIR ?= /var/lib/qubes
STATEDIR ?= /var/run/qubes
LOGDIR ?= /var/log/qubes
Rename vm-configs directory to be more generic
2013-08-02 20:27:33 +02:00
FILESDIR ?= /usr/share/qubes
storage/callback: fix the rpm build
2020-06-30 14:43:55 +02:00
DOCDIR ?= /usr/share/doc/qubes
makefile/windows: use c:\qubes as default data dir
2013-07-30 10:44:20 +02:00
else ifeq ($(OS),Windows_NT)
DATADIR ?= c:/qubes
STATEDIR ?= c:/qubes/state
LOGDIR ?= c:/qubes/log
Rename vm-configs directory to be more generic
2013-08-02 20:27:33 +02:00
FILESDIR ?= c:/program files/Invisible Things Lab/Qubes
storage/callback: fix the rpm build
2020-06-30 14:43:55 +02:00
DOCDIR ?= c:/qubes/doc
makefile/windows: use c:\qubes as default data dir
2013-07-30 10:44:20 +02:00
endif
Initial public commit. (c) 2010 Invisible Things Lab Authors: ========= Joanna Rutkowska <joanna@invisiblethingslab.com> Rafal Wojtczuk <rafal@invisiblethingslab.com>
2010-04-05 20:58:57 +02:00
help:
Makefile improvements for repo management * Sign only current version of the rpms generated * repo-update-{current,unstable} targets for new yum repo
2011-04-04 10:55:25 +02:00
@echo "make rpms -- generate binary rpm packages"
makefile: generic rpms-dom0 and rpms-vm targets
2012-11-14 01:41:21 +01:00
@echo "make rpms-dom0 -- generate binary rpm packages for Dom0"
Makefile improvements for repo management * Sign only current version of the rpms generated * repo-update-{current,unstable} targets for new yum repo
2011-04-04 10:55:25 +02:00
@echo "make update-repo-current -- copy newly generated rpms to qubes yum repo"
Makefile: update-repo-current-testing target
2011-05-09 18:40:51 +02:00
@echo "make update-repo-current-testing -- same, but to -current-testing repo"
Makefile improvements for repo management * Sign only current version of the rpms generated * repo-update-{current,unstable} targets for new yum repo
2011-04-04 10:55:25 +02:00
@echo "make update-repo-unstable -- same, but to -testing repo"
Makefile: update-repo-installer
2011-04-06 15:35:30 +02:00
@echo "make update-repo-installer -- copy dom0 rpms to installer repo"
Makefile improvements for repo management * Sign only current version of the rpms generated * repo-update-{current,unstable} targets for new yum repo
2011-04-04 10:55:25 +02:00
@echo "make clean -- cleanup"
Initial public commit. (c) 2010 Invisible Things Lab Authors: ========= Joanna Rutkowska <joanna@invisiblethingslab.com> Rafal Wojtczuk <rafal@invisiblethingslab.com>
2010-04-05 20:58:57 +02:00
remove VM files
2013-03-07 04:12:37 +01:00
rpms: rpms-dom0
makefile: split rpms into rpms-vm and rpms-dom0 (#665)
2012-11-07 17:58:08 +01:00
remove VM files
2013-03-07 04:12:37 +01:00
rpms-vm:
@true
spec: extract core libs from qubes-core-vm This libs are required by both dom0 and VM so it's better to have it separately. Previously in VM it was separate package, but dom0 have them embedded in qubes-core-dom0, but qubes-core-vm-libs package was used to build qubes-gui-dom0. Now we do not build all packages for all distros (especially do not build core-vm package for dom0 distro, so gui-dom0 build fails), so make it explicit which package is needed by which system.
2012-11-14 13:12:51 +01:00
Remove other Linux-specific stuff Move remaining files to linux/ subdirectory.
2013-03-16 19:54:22 +01:00
rpms-dom0:
makefile: split rpms into rpms-vm and rpms-dom0 (#665)
2012-11-07 17:58:08 +01:00
rpmbuild --define "_rpmdir $(RPMS_DIR)" -bb rpm_spec/core-dom0.spec
Move manpages here from separate repo
2013-03-12 16:55:05 +01:00
rpmbuild --define "_rpmdir $(RPMS_DIR)" -bb rpm_spec/core-dom0-doc.spec
makefile: split rpms into rpms-vm and rpms-dom0 (#665)
2012-11-07 17:58:08 +01:00
rpm --addsign \
Move manpages here from separate repo
2013-03-12 16:55:05 +01:00
$(RPMS_DIR)/x86_64/qubes-core-dom0-$(VERSION)*.rpm \
$(RPMS_DIR)/noarch/qubes-core-dom0-doc-$(VERSION)*rpm
makefile: split rpms into rpms-vm and rpms-dom0 (#665)
2012-11-07 17:58:08 +01:00
rpm+makefile: move build/install code to Makefile files This makes build "scripts" not tied to Fedora-specific files. Especially ease porting to other platforms.
2013-06-15 23:14:54 +02:00
all:
fix Makefile, setup.py, spec and travis QubesOS/qubes-issues#2074
2017-01-20 12:40:00 +01:00
$(PYTHON) setup.py build
makefile: install only relevant stuff according to OS/VMM
2013-07-22 04:18:19 +02:00
# Currently supported only on xen
rpm+makefile: move build/install code to Makefile files This makes build "scripts" not tied to Fedora-specific files. Especially ease porting to other platforms.
2013-06-15 23:14:54 +02:00
install:
makefile: install only relevant stuff according to OS/VMM
2013-07-22 04:18:19 +02:00
ifeq ($(OS),Linux)
rpm+makefile: move build/install code to Makefile files This makes build "scripts" not tied to Fedora-specific files. Especially ease porting to other platforms.
2013-06-15 23:14:54 +02:00
$(MAKE) install -C linux/systemd
$(MAKE) install -C linux/aux-tools
$(MAKE) install -C linux/system-config
makefile: install only relevant stuff according to OS/VMM
2013-07-22 04:18:19 +02:00
endif
fix Makefile, setup.py, spec and travis QubesOS/qubes-issues#2074
2017-01-20 12:40:00 +01:00
$(PYTHON) setup.py install -O1 --skip-build --root $(DESTDIR)
Add qvm-block symlink
2017-07-03 23:07:25 +02:00
ln -s qvm-device $(DESTDIR)/usr/bin/qvm-block
qubes/tools: allow calling qvm-device as qvm-devclass (like qvm-pci) Tool can be symlinked to `qvm-class` for particular device class (for example `qvm-pci`) - then device class can be omitted. QubesOS/qubes-issues#2257
2016-09-03 03:25:52 +02:00
ln -s qvm-device $(DESTDIR)/usr/bin/qvm-pci
ln -s qvm-device $(DESTDIR)/usr/bin/qvm-usb
doc: link qvm-device man page for qvm-block, qvm-pci, qvm-usb Those three are special cases of qvm-device tool, so lets use its documentation too.
2018-01-11 03:44:53 +01:00
install -d $(DESTDIR)/usr/share/man/man1
ln -s qvm-device.1.gz $(DESTDIR)/usr/share/man/man1/qvm-block.1.gz
ln -s qvm-device.1.gz $(DESTDIR)/usr/share/man/man1/qvm-pci.1.gz
ln -s qvm-device.1.gz $(DESTDIR)/usr/share/man/man1/qvm-usb.1.gz
rpm: install RelaxNG specfiles
2015-01-13 23:52:19 +01:00
$(MAKE) install -C relaxng
Merge remote-tracking branch 'marmarek/master' into core3-devel The following list is bollocks. There were many, many more. Conflicts: core-modules/003QubesTemplateVm.py core-modules/005QubesNetVm.py core/qubes.py core/storage/__init__.py core/storage/xen.py doc/qvm-tools/qvm-pci.rst doc/qvm-tools/qvm-prefs.rst qubes/tools/qmemmand.py qvm-tools/qvm-create qvm-tools/qvm-prefs qvm-tools/qvm-start tests/__init__.py vm-config/xen-vm-template-hvm.xml This commit took 2 days (26-27.01.2016) and put our friendship to test. --Wojtek and Marek
2016-03-03 01:05:23 +01:00
mkdir -p $(DESTDIR)/etc/qubes
makefile: install only relevant stuff according to OS/VMM
2013-07-22 04:18:19 +02:00
ifeq ($(BACKEND_VMM),xen)
# Currently supported only on xen
core3: move qmemman This is part of fixing qvm-start. qmemman was moved with minimal touching, mainly module names. Moved function parsing human-readable sizes from core2. This function is wrong, because it treats k/M/G as 1024-based, but leave it for now.
2015-10-01 22:14:35 +02:00
cp etc/qmemman.conf $(DESTDIR)/etc/qubes/
makefile: install only relevant stuff according to OS/VMM
2013-07-22 04:18:19 +02:00
endif
Convert default qrexec policy to the new format QubesOS/qubes-issues#4370
2020-05-12 05:01:36 +02:00
mkdir -p $(DESTDIR)/etc/qubes-rpc
mkdir -p $(DESTDIR)/etc/qubes/policy.d
move qubes-notify-* to libexec
2013-07-22 04:13:12 +02:00
mkdir -p $(DESTDIR)/usr/libexec/qubes
Convert default qrexec policy to the new format QubesOS/qubes-issues#4370
2020-05-12 05:01:36 +02:00
install -m 0644 qubes-rpc-policy/90-default.policy \
$(DESTDIR)/etc/qubes/policy.d/90-default.policy
qubes/tools/qvm-features: add tool for managing qvm-features QubesOS/qubes-issues#1637
2016-05-17 18:12:24 +02:00
cp qubes-rpc/qubes.FeaturesRequest $(DESTDIR)/etc/qubes-rpc/
Add qubes.GetDate proxy service This enable two things: 1. Follow global clockvm setting, without adjusting qrexec policy. 2. Avoid starting clockvm by arbitrary VM. Fixes QubesOS/qubes-issues#3588
2018-03-02 20:39:28 +01:00
cp qubes-rpc/qubes.GetDate $(DESTDIR)/etc/qubes-rpc/
implemented dom0 qubes.GetRandomizedTime Required for fixing 'sys-whonix doesn't connect to Tor after system suspend'. https://github.com/QubesOS/qubes-issues/issues/1764
2016-03-13 02:15:46 +01:00
cp qubes-rpc/qubes.GetRandomizedTime $(DESTDIR)/etc/qubes-rpc/
qubes/tools/qvm-features: add tool for managing qvm-features QubesOS/qubes-issues#1637
2016-05-17 18:12:24 +02:00
cp qubes-rpc/qubes.NotifyTools $(DESTDIR)/etc/qubes-rpc/
cp qubes-rpc/qubes.NotifyUpdates $(DESTDIR)/etc/qubes-rpc/
Add qubes.ConnectTCP RPC for allowing dom0 sockets binding
2019-08-29 11:40:06 +02:00
cp qubes-rpc/qubes.ConnectTCP $(DESTDIR)/etc/qubes-rpc/
Install qubes-hcl-report and qubes-bug-report Fixes QubesOS/qubes-issues#3023
2017-08-14 02:26:34 +02:00
install -m 0755 qvm-tools/qubes-bug-report $(DESTDIR)/usr/bin/qubes-bug-report
install -m 0755 qvm-tools/qubes-hcl-report $(DESTDIR)/usr/bin/qubes-hcl-report
clock synchronization rewrite clock synchronization mechanism rewritten to use systemd-timesync instead of NtpDate; at the moment, requires: - modifying /etc/qubes-rpc/policy/qubes.GetDate to redirect GetDate to designated clockvm - enabling clocksync service in clockvm ( qvm-features clockvm-name service/clocksync true ) Works as specified in issue listed below, except for: - each VM synces with clockvm after boot and every 6h - clockvm synces time with the Internet using systemd-timesync - dom0 synces itself with clockvm every 1h (using cron) fixes QubesOS/qubes-issues#1230
2017-07-06 23:37:26 +02:00
install -m 0755 qvm-tools/qvm-sync-clock $(DESTDIR)/usr/bin/qvm-sync-clock
Rename and fix from Marek's comments
2019-05-07 13:54:29 +02:00
install -m 0755 qvm-tools/qvm-console-dispvm $(DESTDIR)/usr/bin/qvm-console-dispvm
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
for method in $(ADMIN_API_METHODS_SIMPLE); do \
Make qubesd connected directly as an socket qrexec service Remove intermediate qubesd-query-fast proxy process. This requires changing socket protocol to match what qrexec is sending in the header. Fixes QubesOS/qubes-issues#3293
2020-04-20 03:29:29 +02:00
ln -s ../../var/run/qubesd.sock \
Generate policy for Admin API calls based on annotations on actual methods This ease Admin API administration, and also adds checking if qrexec policy + scripts matches actual Admin API methods implementation. The idea is to classify every Admin API method as either local read-only, local read-write, global read-only or global read-write. Where local/global means affecting a single VM, or the whole system. See QubesOS/qubes-issues#2871 for details. Fixes QubesOS/qubes-issues#2871
2017-06-27 01:55:17 +02:00
$(DESTDIR)/etc/qubes-rpc/$$method || exit 1; \
admin-api: create and install actual Admin API RPC endpoints Install files in /etc/qubes-rpc for all methods defined in API documentation, even if not yet implemented (qubesd will handle it raising appropriate exception). Use minimal program written in C (qubesd-query-fast), instead of qubesd-query in python for performance reasons: - a single qubesd-query run: ~300ms - equivalent in shell (echo | nc -U): ~40ms - qubesd-query-fast: ~20ms Many tools makes multiple API calls, so performance here do matter. For example qvm-ls (from VM) currently takes about 60s on a system with 24 VMs. Also make use of `$include:` directive in policy file, to make it easier defining a VM with full Admin API access. QubesOS/qubes-issues#853
2017-05-23 03:24:15 +02:00
done
admin: implement admin.vm.volume.Import Implement this in two parts: 1. Permissions checks, getting a path from appropriate storage pool 2. Actual data import The first part is done by qubesd in a standard way, but then, instead of accepting all the data (which may be several GB), return a path to which a shell script (in practice: `dd` command) will write the data. Then the script call back to qubesd again to report success/failure and qubesd response from that call is actually returned to the user. This way we do not pass all the data through qubesd, but still can control the process from there in a meaningful way. Note that the last part (second call to qubesd) may perform all kind of verification (like a signature check on the data, or so) and can also prevent VM from starting (hooking also domain-pre-start event) from not verified image. QubesOS/qubes-issues#2622
2017-05-23 15:38:28 +02:00
install qubes-rpc/admin.vm.volume.Import $(DESTDIR)/etc/qubes-rpc/
Implement new admin.vm.ImportWithSize API call This should allow importing a volume and changing the size at the same time, without performing the resize operation on original volume first. The internal API has been renamed to internal.vm.volume.ImportBegin to avoid confusion, and for symmetry with ImportEnd. See QubesOS/qubes-issues#5239.
2020-01-16 14:41:00 +01:00
ln -s admin.vm.volume.Import $(DESTDIR)/etc/qubes-rpc/admin.vm.volume.ImportWithSize
Rename and fix from Marek's comments
2019-05-07 13:54:29 +02:00
install qubes-rpc/admin.vm.Console $(DESTDIR)/etc/qubes-rpc/
Generate policy for Admin API calls based on annotations on actual methods This ease Admin API administration, and also adds checking if qrexec policy + scripts matches actual Admin API methods implementation. The idea is to classify every Admin API method as either local read-only, local read-write, global read-only or global read-write. Where local/global means affecting a single VM, or the whole system. See QubesOS/qubes-issues#2871 for details. Fixes QubesOS/qubes-issues#2871
2017-06-27 01:55:17 +02:00
PYTHONPATH=.:test-packages qubes-rpc-policy/generate-admin-policy \
Convert default qrexec policy to the new format QubesOS/qubes-issues#4370
2020-05-12 05:01:36 +02:00
--dest=$(DESTDIR)/etc/qubes/policy.d/90-admin-default.policy \
--header=qubes-rpc-policy/90-admin-default.policy.header \
Generate policy for Admin API calls based on annotations on actual methods This ease Admin API administration, and also adds checking if qrexec policy + scripts matches actual Admin API methods implementation. The idea is to classify every Admin API method as either local read-only, local read-write, global read-only or global read-write. Where local/global means affecting a single VM, or the whole system. See QubesOS/qubes-issues#2871 for details. Fixes QubesOS/qubes-issues#2871
2017-06-27 01:55:17 +02:00
--exclude admin.vm.Create.AdminVM \
admin.vm.CreateInPool.AdminVM \
admin.vm.device.testclass.Attach \
admin.vm.device.testclass.Detach \
admin.vm.device.testclass.List \
api/admin: implement admin.vm.device....Set.persistent This will allow converting persistent device (used to boot VM for example) to non-persistent. QubesOS/qubes-issues#3055
2017-09-02 17:59:29 +02:00
admin.vm.device.testclass.Set.persistent \
Generate policy for Admin API calls based on annotations on actual methods This ease Admin API administration, and also adds checking if qrexec policy + scripts matches actual Admin API methods implementation. The idea is to classify every Admin API method as either local read-only, local read-write, global read-only or global read-write. Where local/global means affecting a single VM, or the whole system. See QubesOS/qubes-issues#2871 for details. Fixes QubesOS/qubes-issues#2871
2017-06-27 01:55:17 +02:00
admin.vm.device.testclass.Available
Convert default qrexec policy to the new format QubesOS/qubes-issues#4370
2020-05-12 05:01:36 +02:00
install -d $(DESTDIR)/etc/qubes/policy.d/include
Generate policy for Admin API calls based on annotations on actual methods This ease Admin API administration, and also adds checking if qrexec policy + scripts matches actual Admin API methods implementation. The idea is to classify every Admin API method as either local read-only, local read-write, global read-only or global read-write. Where local/global means affecting a single VM, or the whole system. See QubesOS/qubes-issues#2871 for details. Fixes QubesOS/qubes-issues#2871
2017-06-27 01:55:17 +02:00
install -m 0644 qubes-rpc-policy/admin-local-ro \
qubes-rpc-policy/admin-local-rwx \
qubes-rpc-policy/admin-global-ro \
qubes-rpc-policy/admin-global-rwx \
Convert default qrexec policy to the new format QubesOS/qubes-issues#4370
2020-05-12 05:01:36 +02:00
$(DESTDIR)/etc/qubes/policy.d/include/
core3: move qmemman This is part of fixing qvm-start. qmemman was moved with minimal touching, mainly module names. Moved function parsing human-readable sizes from core2. This function is wrong, because it treats k/M/G as 1024-based, but leave it for now.
2015-10-01 22:14:35 +02:00
Rename vm-configs directory to be more generic
2013-08-02 20:27:33 +02:00
mkdir -p "$(DESTDIR)$(FILESDIR)"
HVM part 1
2016-03-02 12:17:29 +01:00
cp -r templates "$(DESTDIR)$(FILESDIR)/templates"
rm -f "$(DESTDIR)$(FILESDIR)/templates/README"
core3: move qmemman This is part of fixing qvm-start. qmemman was moved with minimal touching, mainly module names. Moved function parsing human-readable sizes from core2. This function is wrong, because it treats k/M/G as 1024-based, but leave it for now.
2015-10-01 22:14:35 +02:00
storage/callback: fix the rpm build
2020-06-30 14:43:55 +02:00
mkdir -p "$(DESTDIR)$(DOCDIR)"
cp qubes/storage/callback.json.example "$(DESTDIR)$(DOCDIR)/qubes_callback.json.example"
makefile/windows: use c:\qubes as default data dir
2013-07-30 10:44:20 +02:00
mkdir -p $(DESTDIR)$(DATADIR)
mkdir -p $(DESTDIR)$(DATADIR)/vm-templates
mkdir -p $(DESTDIR)$(DATADIR)/appvms
mkdir -p $(DESTDIR)$(DATADIR)/servicevms
mkdir -p $(DESTDIR)$(DATADIR)/vm-kernels
mkdir -p $(DESTDIR)$(DATADIR)/backup
mkdir -p $(DESTDIR)$(DATADIR)/dvmdata
mkdir -p $(DESTDIR)$(STATEDIR)
mkdir -p $(DESTDIR)$(LOGDIR)
rpm+makefile: move build/install code to Makefile files This makes build "scripts" not tied to Fedora-specific files. Especially ease porting to other platforms.
2013-06-15 23:14:54 +02:00
windows: installer
2013-09-26 22:28:37 +02:00
msi:
rm -rf destinstdir
mkdir -p destinstdir
$(MAKE) install \
DESTDIR=$(PWD)/destinstdir \
PYTHON_SITEPATH=/site-packages \
FILESDIR=/pfiles \
BINDIR=/bin \
DATADIR=/qubes \
STATEDIR=/qubes/state \
LOGDIR=/qubes/log
# icons placeholder
mkdir -p destinstdir/icons
for i in blue gray green yellow orange black purple red; do touch destinstdir/icons/$$i.png; done
candle -arch x64 -dversion=$(VERSION) installer.wxs
light -b destinstdir -o core-admin.msm installer.wixobj
rm -rf destinstdir
Reference in New Issue Copy Permalink