Do not use a symlink there, as it will be left after NetworkManager
shutdown - as a broken link then
FixesQubesOS/qubes-issues#2320
Reported by Achim Patzner <noses@noses.com>
* origin/pr/77:
archlinux: fix update-proxy-configs to use pacman.d drop-ins
archlinux: ensure repositories are the last pacman.d files included
archlinux: Setup default package repository
archlinux: switch to usage of pacman.d drop-ins
For a long time the DNS address was the same as default gateway. This is
still the case in R3.x, but using `qubes-gateway` configuration
parameter for it is misleading. It should be up to dom0 to provide DNS
address (whether the value is the same as gateway or not).
FixesQubesOS/qubes-issues#1817
Explicitly block something like "curl http://10.137.255.254:8082" and
return error page in this case. This error page is used in Whonix to
detect if the proxy is torrified. If not blocked, it may happen that
empty response is returned instead of error. See linked ticket for
details.
FixesQubesOS/qubes-issues#1482
Apparently unmanaged devices are loaded only from main
NetworkManager.conf. Exactly the same line pasted (not typed!) to main
NetworkManager.conf works, but in
/etc/NetworkManager/conf.d/30-qubes.conf it doesn't.
BTW There was a typo in option name ("unmanaged_devices" instead of
"unmanaged-devices", but it wasn't the cause).
This reverts commit 6c4831339c.
QubesOS/qubes-issues#1176
Since this proxy is used only when explicitly configured in application
(package manager), there is no point in worrying about user
_erroneously_ using web browser through this proxy. If the user really
want to access the network from some other application he/she can always
alter firewall rules for that.
FixesQubesOS/qubes-issues#1188
Previously even if NetworkManager was enabled, our script manually
configured network parameters. This apparently have negative effects,
because NetworkManager tries to configure some things differently - for
example use metric 1024 for default gateway.
FixesQubesOS/qubes-issues#1052
Each time some arbitrary package was installed using dpkg or apt-get, the update notification in Qubes VM Manager was cleared.
No matter if there were still updates pending. (Could happen even after the user running `apt-get dist-upgrade` in case of package manager issues.)
No longer clear upgrade notification in QVMM on arbitrary package installation.
Check if upgrades have been actually installed before clearing the notifications.
https://github.com/QubesOS/qubes-issues/issues/1066#issuecomment-150044906
Don't use ${CONF_PATH}.qubes, because it may override some existing
file, and is racy approach (even if not against user, but another script
instance).
QubesOS/qubes-issues#1282
According to the specification[1], the setting name is 'addresses', not
'address'. The later apparently worked on some NetworkManager versions,
but for example not on the one in Debian wheezy. Also fix value
format (IP;netmask;gateway).
[1] htts://developer.gnome.org/NetworkManager/unstable/ref-settings.html
FixesQubesOS/qubes-issues#1280
Do not modify main /etc/NetworkManager/NetworkManager.conf as it would
cause conflicts during updates. Use
/etc/NetworkManager/conf.d/30-qubes.conf instead.
Also remove some dead code for dynamically generated parts (no longer
required to "blacklist" eth0 in VMs - we have proper connection
generated for it). It was commented out for some time already
FixesQubesOS/qubes-issues#1176
There were multiple problems with reusing existing one:
- need to sync with upstream changes (configuration path etc)
- conflicts resolution on updates
- lack of iptables --wait, which causes firewall fail to load sometimes
QubesOS/qubes-issues#1067
Apparently even iptables-restore does not handle concurrent firewall
updates. This is especially a problem in case of HVM, which have two
network interfaces (one through stubom and the other direct) added at
the same time.
The later one is present only in latest iptables version - especially
debian does not have it. But we need to handle "Device or resources
busy" problem somehow.
There is a possiblilty of the apt-get post hook getting triggered
more than once for each apt-get session, therefore we only notify
dom0 that there are no updates available and do not perform an
apt-get update.
The qubes-update-check.service will still perform an update so even
if the dist-upgrade failed and there was actually more files to update
the qubes-update-check.serivce would then at some point notify dom0
about those updates being available
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJVO0XmAAoJEBu5sftaTG2tTpsQAJaSV/4vUt1R+HloAxpiAkQQ
ai6C9r0jXEDOggO+jqeNLhM6ZaFxPOqI7+O09EXoRQXnFjtXPq6V4Yj8vr7urh5Z
ozg3K2atQ6htvoDjqktSHuMwJLTGCHDCKzHV/uvZlFT0o90XomGLAJ+3RuWqgZu7
5h+jnzfo+pLxme2jiCFQvFQ+p6Y+yZiphiUc5HbnIs4aTvDJxKmhZHMXVshbFJQe
wPr1kp4xdefiys5A5agKejPOdQm8z4PVzZfnehfQZholkKlYFSgOLc7s4qJ+WOFl
Bwl8B0Nm4LqIr0hkyEvPBX7PwmAu8/2aHeEj423rLXCDvHjGbmDWE99LSRvDYFK4
nuZkrR+dI0kbYqtfkWH8MMfu/YHcC+uHrkVbLpqV4r8F8jT/f6ysyJ/kb76WoVEK
B2q/nfBjtcHXOb/7GT/Q8MIvIXDsAVNp9jtEiQ/u/Jr8T7t9GtuQbgy1Y+eDOl4G
Hg5635qfj6SImKtj6e4VqOb968TqeE0qoqBeLFEG2boqyVOjHbfk8gj5IZParp3R
WfZDAS6OpY95W+gJzH0rBUh0h5fcuB+aN16ak4snaDxwd6gl9NfdPOydt4zQTs4q
tmKnyuXig5age0IgGFliubdWlAL72GSN8M+uBp+Pe0QoEoJRPN3AiaY63OgUBk9S
ID6TzMI990IRIxGTQnho
=nJSZ
-----END PGP SIGNATURE-----
Merge tag 'jm_21d89335'
Tag for commit 21d89335fe
# gpg: Signature made Sat Apr 25 09:44:38 2015 CEST using RSA key ID 5A4C6DAD
# gpg: Good signature from "Jason Mehring (Qubes OS Signing Key) <nrgaway@gmail.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: E0E3 2283 FDCA C1A5 1007 8F27 1BB9 B1FB 5A4C 6DAD
* tag 'jm_21d89335':
debian: Update notification now notifies dom0 when an upgrade is completed
