Re: [qubes-users] Have to drop Qubes because of company policy: workarounds?

2019-09-09 Thread Pablo Di Noto
Hello,


> > It is clear that despite ticking the check boxes from the auditor point 
> of 
> > view with this idea, I would be willingly violating the internal rules 
> they 
> > have setup, and maybe risking the company certification in case of a 
> deeper 
> > review after an incident. Despite the overall lack of consideration for 
> > specific (and arguably better) security setups, doing this hack will 
> have 
> > me connecting to our internal networks and avoiding the endpoint 
> security 
> > scan the applications really using them. 
>
> The auditors might be satisfied if you are able to explain how Qubes 
> itself is a compensating control on the limited file scanning ability of 
> your AV, but doing so could be a challenge. 
>

Yes, it is challenge in many levels. Been thru five companies during their 
PCIDSS certification, for instance, and the way the whole business work is 
to promote the usage of know things, despite their real security value.

To give and rough idea, a relatively patched Windows machine will always be 
seen as a more compliant endpoint device that using Chromebook.
If Google is not yet able to get that into the "nobody got fired by" circle 
despite having a huge financial backing and a decent usage track , imagine 
the relatively obscure OS we love.

On the bright side, all auditors I spoke to are either a) aware of Qubes as 
state of the art in secure endpoint (given a decently trained user, that 
is) or b) Amazed when told and show how it works.
 

> For a really ugly hack, you might be able to readonly loop mount -pool00 
> (and -root?) into a network connected AppVM running your AV, so it could 
> scan them as large files. This breaks the Qubes security model pretty 
> thoroughly, but would make auditors happy I guess. You'd at least have 
> the benefit of continuing to use Qubes.


I soon have the annual company meeting, and may find a suitable stop to 
discuss this with my managers.
Will be an interesting talk, for sure.

Thanks for the idea, will check how S1 deals with images and raw 
filesystems.

Cheers,
///Pablo

 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/42eda180-f125-4ea5-a2ed-e1440db2786d%40googlegroups.com.


Re: [qubes-users] Have to drop Qubes because of company policy: workarounds?

2019-09-09 Thread Pablo Di Noto
Hello,
 

> > > I think you may be overstating the problem of running anti-virus on 
> > > Qubes. If you could find an AV that updates its virus definitions via 
> > > signed RPMs, then it can be made to work without a lot of effort. 
> > > 
> > 
> > The issue in this case is two fold: The designated ~antivius~ endpoint 
> > protection solution (Sentinel One in our case) offers no support for 
> > Fedora, specially an oldish one like F25. Also, the whole compliance 
> point 
> > is to have the endpoint report frequently its compliance status, which 
> dom0 
> > would not do. 
> > And, of course, this solution has its own update mechanism, so it cannot 
> be 
> > made work with the RPM proxy Qubes offers. 
>
> 1) Create a standalone VM called sys-net-work based on Debian. 
> 2) Install your AV there. 
> 3) When you are at work boot that one and map your firewall to it instead 
> of 
> the standard sys-net. 
>
> This is equivalent to a non hypervisor OS as sys-net is the root of the 
> system and through it flows all network traffic. 
>
> This should check your management's tick box as sentinel will report back 
> that it is running. 
>
> And it should meet your needs as you can stay on qubes OS and additionally 
> remap to sys-net when you are home so you need not run their closed source 
> "security" software when you are not obliged to. 
>
>
That is, indeed, a clever hack.
I did not think about installing the endpoint security software on a 
`sys-net` role VM.

Fortunately my organization is ran by very bright technical people, with 
whom I interact everyday. 
It is clear that despite ticking the check boxes from the auditor point of 
view with this idea, I would be willingly violating the internal rules they 
have setup, and maybe risking the company certification in case of a deeper 
review after an incident. Despite the overall lack of consideration for 
specific (and arguably better) security setups, doing this hack will have 
me connecting to our internal networks and avoiding the endpoint security 
scan the applications really using them.

Thanks a lot for you idea!
Regards,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/68612fc1-99b2-4924-bca0-5186942b8d36%40googlegroups.com.


Re: [qubes-users] Have to drop Qubes because of company policy: workarounds?

2019-09-07 Thread Pablo Di Noto
Hello,
 

> I think you may be overstating the problem of running anti-virus on 
> Qubes. If you could find an AV that updates its virus definitions via 
> signed RPMs, then it can be made to work without a lot of effort. 
>

The issue in this case is two fold: The designated ~antivius~ endpoint 
protection solution (Sentinel One in our case) offers no support for 
Fedora, specially an oldish one like F25. Also, the whole compliance point 
is to have the endpoint report frequently its compliance status, which dom0 
would not do.
And, of course, this solution has its own update mechanism, so it cannot be 
made work with the RPM proxy Qubes offers.


> Beyond that, you could still do it without RPMs, assuming the AV program 
> requires all of its data to be signed. 
>
> - 
>
> Whatever AV installation you had in dom0 would also need to be installed 
> in a template as well... this allows DispVMs to scan your various 
> working VMs while still maintaining isolation. The definition update 
> mechanism for the template would be the same as for dom0 (i.e. import an 
> RPM, or some other signed data file via qvm-copy). 
>

I see no issue with that.
Unfortunately, from my company point of view, having only all VMs with the 
endpoint security software would not make me compliant.

Thanks for your comments!
///Pablo

>
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ca6a5923-15f7-42c2-a0c4-d2179b61abcd%40googlegroups.com.


[qubes-users] Have to drop Qubes because of company policy: workarounds?

2019-09-07 Thread Pablo Di Noto
Hello!

I have been a Qubes user for 3+ years and adopted its separation-of-concern 
model deeply into my day to day activities.

A year ago I started to work for a cloud company that is 
seeking/re-certifying several security certifications, and among the 
requirement of these certifications are strict policies that require any 
organization member accessing any company resource to have a certified 
antivirus solution installed on their computer(s), including Linux. That is 
a very common requirement for corporate work. 

Unfortunately, these policies leave much room for interpretation, and 
companies tend to lean on the safe side to avoiding corner cases that may 
"upset" the certification auditing teams.

Long story short, as Qubes cannot run (and does not make any sense to run) 
a self-updating, status reporting antivirus on dom0, it is not compliant.

Sad times, as I will be having to go back many, many steps back in terms of 
real security and data protection in order to use one of the main 
distributions.

My managers are ok for me to to use xen (or other hypervisor, for that 
matter) and a compliant distribution as dom0 which would make the whole 
thing almost indistinguishable from a regular endpoint to any auditor.

Now finally the question: How difficult would be to have a Xen-based Fedora 
(or better, Debian) dom0 and then install the libvirt and qubes middleware 
for template handling, inter VM communications, etc? I know that would 
require a cumbersome install process, but does seem feasible. At the same 
time, it could be a nice experience in terms of testing Qubes middleware 
into multiple dom0 environments. 

I know there are security implications to this: All the hardening on 
non-connected dom0 would be lost, the use of a off-the-shelf dom0 may bring 
lots of attack vectors, all installation-time setup of sys-* VMs would have 
to be redone manually, etc. But the final product would have the 
isolation-by-nature workflow I grew to love.

Thanks for any advice about feasibility of this.
Cheers,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/282a9871-cd1a-421e-86cb-c4bdc263ff8b%40googlegroups.com.


[qubes-users] Re: qvm-run, hangs and stacktrace.

2018-08-27 Thread Pablo Di Noto
Well, I think I found the reason:

When I updated my debian-9 template, there was a conflict of packages 
dependencies that made `qubes-gui-agent` become uninstalled. Obviously, with 
that package missing, any GUI interaction with the VMs depending on that 
template fails (and qvm-* commands hang forever).

I fixed the issue by messing with `aptitude` and the "(b) broken packages" 
option, and then selecting a solution that did this:

Start-Date: 2018-08-27  18:56:55
Install: xserver-xorg-video-dummyqbs:amd64 (4.0.15-1+deb9u1, automatic), 
qubes-gui-agent:amd64 (4.0.15-1+deb9u1)
Downgrade: xserver-xorg-video-vesa:amd64 (1:2.4.0-1, 1:2.3.4-1+b2), 
xserver-xorg-video-nouveau:amd64 (1:1.0.15-3, 1:1.0.13-3), 
xserver-xorg-video-amdgpu:amd64 (18.0.1-1+b1, 1.2.0-1+b1), 
xserver-xorg-core:amd64 (2:1.20.1-1, 2:1.19.2-1+deb9u2), 
xserver-xorg-video-fbdev:amd64 (1:0.5.0-1, 1:0.4.4-1+b5), 
xserver-xorg-video-ati:amd64 (1:18.0.1-2, 1:7.8.0-1+b1), 
xserver-xorg-video-radeon:amd64 (1:18.0.1-2, 1:7.8.0-1+b1)
Remove: xserver-xorg-video-dummy:amd64 (1:0.3.8-1+b1), 
libmagickcore-6.q16-5-extra:amd64 (8:6.9.9.34+dfsg-3+b1), 
xserver-xorg-video-r128:amd64 (6.11.0-1), libavformat57:amd64 (7:3.4.3-1), 
xserver-xorg-video-qxl:amd64 (0.1.5-2+b1), libargon2-0:amd64 (0~20171227-0.1), 
xserver-xorg-video-cirrus:amd64 (1:1.5.3-1+b3), 
linux-headers-4.16.0-2-common:amd64 (4.16.16-2), libmagickwand-6.q16-5:amd64 
(8:6.9.9.34+dfsg-3+b1), xserver-xorg-video-trident:amd64 (1:1.3.8-1+b1), 
libxatracker2:amd64 (18.1.6-1), linux-headers-4.16.0-2-amd64:amd64 (4.16.16-2), 
xserver-xorg-video-savage:amd64 (1:2.3.9-2), libpostproc54:amd64 (7:3.4.3-1), 
libgeoclue-2-0:amd64 (2.4.12-1), libstdc++-7-dev:amd64 (7.3.0-28), 
libnfs8:amd64 (1.11.0-2), xserver-xorg-video-mach64:amd64 (6.9.6-1), 
libx264-148:amd64 (2:0.148.2748+git97eaef2-1), libx265-95:amd64 (2.1-2+b2), 
g++-7:amd64 (7.3.0-28), libgfortran4:amd64 (7.3.0-28), 
xserver-xorg-video-intel:amd64 (2:2.99.917+git20171229-1+b1), 
xserver-xorg-video-tdfx:amd64 (1:1.4.7-1+b1), xserver-xorg-video-vmware:amd64 
(1:13.3.0-2), xserver-xorg-video-all:amd64 (1:7.7+19), libswscale4:amd64 
(7:3.4.3-1), libdns-export1100:amd64 (1:9.11.3+dfsg-2), 
libmagickcore-6.q16-5:amd64 (8:6.9.9.34+dfsg-3+b1), libgcab-1.0-0:amd64 
(1.1-3), bdf2psf:amd64 (1.184), xserver-xorg-video-neomagic:amd64 
(1:1.2.9-1+b3), libva-wayland1:amd64 (1.7.3-2), liblivemedia57:amd64 
(2016.11.28-1), linux-kbuild-4.16:amd64 (4.16.16-2), libbluray1:amd64 
(1:0.9.3-3), xserver-xorg-video-mga:amd64 (1:1.6.5-1+b1), libavresample3:amd64 
(7:3.4.3-1), xserver-xorg-video-openchrome:amd64 (1:0.6.0-3+b1)
End-Date: 2018-08-27  18:57:05

After that, it is possible to do

systemctl enable qubes-gui-agent.service
systemctl start qubes-gui-agent.service

and from that point on, the template is operating normally.

Hope it helps!
///Pablo

El miércoles, 15 de agosto de 2018, 8:29:40 (UTC-3), tier...@gmail.com escribió:
> On Tuesday, August 14, 2018 at 4:36:29 PM UTC+1, Pablo Di Noto wrote:
> > Kudos to the `qvm-volume revert` feature!
> > 
> > I just did
> > ```
> > qvm-volume info debian-9-root
> > qvm-volume revert debian-9-root XX-back
> > ```
> > and went back to the pre-update template and the issue disappeared.
> > 
> > Later today will try to see what happened by updating a clone of the 
> > template (as I should have done in the first place)
> 
> Not an option for me. I shall file a bug report.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/be4b921c-1d0a-48b2-8c80-b0656ecf008b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] qvm-run, hangs and stacktrace.

2018-08-14 Thread Pablo Di Noto
Kudos to the `qvm-volume revert` feature!

I just did
```
qvm-volume info debian-9-root
qvm-volume revert debian-9-root XX-back
```
and went back to the pre-update template and the issue disappeared.

Later today will try to see what happened by updating a clone of the template 
(as I should have done in the first place)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bbf26739-d824-4872-b920-f49c3f0534cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] qvm-run, hangs and stacktrace.

2018-08-14 Thread Pablo Di Noto
Further troubleshooting shows last Debian template update I did recently seems 
to be the reason (I normally use Debian for sys-* service VMs)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/70aa4ee4-5d1b-4532-a505-46693aa8ec25%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] qvm-run, hangs and stacktrace.

2018-08-14 Thread Pablo Di Noto
Further troubleshooting shows last Debian template seems to be the reason (I 
normally use Debian for sys-* service VMs)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8c5e2376-b83a-49e6-8049-7063a9796982%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] qvm-run, hangs and stacktrace.

2018-08-14 Thread Pablo Di Noto
I updated last night to testing, and now qvm-run just hangs. Terminating it 
with CTRL-C gives the same traceback.

Please note that in my case, starting any application from the dom0 menu is now 
working at all. Seems there is issue with the X session.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/92b27b3d-8437-4db3-b65a-10c4c2b72185%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: redshift

2018-05-01 Thread Pablo Di Noto
El martes, 1 de mayo de 2018, 19:07:35 (UTC), haaber escribió:
> it would be a nice feature to have a program like redshift
> https://doc.ubuntu-fr.org/redshift running in dom0. Did anyone have such
> software running in qubes (I am on Q4).  Thank you,

I am using it since R3.0 and had no issue installing it the way mst explained 
above.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6dc29ee9-35de-413f-a881-4629fd8ceecb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Wrong timezone in VMs: where the value for qubesdb-read /qubes-timezone comes from? (Take two)

2018-05-01 Thread Pablo Di Noto
Hello Ivan,

El mar., 1 may. 2018 01:13, Ivan Mitev <i...@maa.bz> escribió:

> Hi,
>
> On 05/01/2018 03:18 AM, Pablo Di Noto wrote:
> > Hello all,
> >
> > I asked this question when Qubes R3.2 was out, and solved with help from
> Andrew in a somewhat weird way (running local scripts on each AppVM).
> >
> > Now that we are at R4.0, I am again having this issue:
> >
> > After install, dom0 gets proper timezone:
> >
> > |[root@dom0 Desktop]# timedatectl
> > |  Local time: Mon 2018-04-30 21:12:20 -03
> > |  Universal time: Tue 2018-05-01 00:12:20 UTC
> > |RTC time: Tue 2018-05-01 00:12:20
> > |   Time zone: America/Argentina/Cordoba (-03, -0300)
> > | Network time on: no
> > |NTP synchronized: no
> > | RTC in local TZ: no
> >
> > but for some reason, all AppVM get the wrong timezone on their
> configuration script:
> >
> > |user@p-vault:~/p-vault$ ls -l /etc/localtime
> > |lrwxrwxrwx 1 root root 39 Apr 30 23:32 /etc/localtime ->
> ../usr/share/zoneinfo/Argentina/Cordoba
> >
> > which of course does not exists, so all AppVM end up in GMT.
> >
> > So my original question is back: Where does that value come from?
> /usr/lib/qubes/init/qubes-early-vm-config.sh
>

Yes, I see it.

That is why I was after the source of  the "Argentina/Cordoba" as answer to
"qubesdb-read /qubes-timezone" on any AppVM.

For some reason, despite dom0 has proper "America/Argentina/Cordoba"
timezone after a clean install, AppVMs get "Argentina/Cordoba" when they
ask dom0.

Will check qubesdb code to see if there is some hardcoded regexp that is
asuming timezones are only "" or "/" break when it is three
item "//"

Regards,
///Pablo

>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAOJFbN8BQ-_sdO-tcjGDO1v%3D7xV55Q8sBjFWU8YP5LXsipxVeA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Wrong timezone in VMs: where the value for qubesdb-read /qubes-timezone comes from? (Take two)

2018-04-30 Thread Pablo Di Noto
Hello all,

I asked this question when Qubes R3.2 was out, and solved with help from Andrew 
in a somewhat weird way (running local scripts on each AppVM).

Now that we are at R4.0, I am again having this issue:

After install, dom0 gets proper timezone:

|[root@dom0 Desktop]# timedatectl
|  Local time: Mon 2018-04-30 21:12:20 -03
|  Universal time: Tue 2018-05-01 00:12:20 UTC
|RTC time: Tue 2018-05-01 00:12:20
|   Time zone: America/Argentina/Cordoba (-03, -0300)
| Network time on: no
|NTP synchronized: no
| RTC in local TZ: no

but for some reason, all AppVM get the wrong timezone on their configuration 
script:

|user@p-vault:~/p-vault$ ls -l /etc/localtime 
|lrwxrwxrwx 1 root root 39 Apr 30 23:32 /etc/localtime -> 
../usr/share/zoneinfo/Argentina/Cordoba

which of course does not exists, so all AppVM end up in GMT.

So my original question is back: Where does that value come from?
And the obvious next one: How can I change it to a proper 
"America/Argentina/Cordoba"?

Thanks!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/698c13f7-532a-4d23-8d08-034e19785b8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] sys-net cannot start because private image unavailable, 'vm-sys-net-private-tmp' exists

2018-04-26 Thread Pablo Di Noto
Hello,

After a normal reboot I had a working dom0 without any ServiceVM started.
Found that `sys-net` could not start because the 'vm-sys-net-private' LVM 
volume was missing.

Looking around I found that the '-tmp' version of it was available, and after 
mounting it I could see the contents of the working 'sys-net' rw volume, so I 
renamed it back to the proper name and then evertything worked fine.

I am assuming some kind of interrupted internal renaming happened.

What would be the proper way to enable debugging on Qubes LVM operations? Many 
qvm-* commands --verbose do nothing. Would like to understand the root cause of 
this if it happens again, but also to understand the inner workings of the 
Qubes volumen management.

Sometimes I have a 45 second delay from a `qvm-start` and anything showing up 
on `xl list`, and I suspect some LVM operations may be taking long time to 
execute.

Regards,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/eada3b83-6cc3-47c4-beaf-ed1f3eeea004%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

2018-04-12 Thread Pablo Di Noto

> > > > You could also try to revert to earlier revision using "qvm-volume
> > revert sys-net:private" for example.
> 
> Will try that tonight.
> 

Unfortunately, that was not possible for the service VMs.
For the only important AppVM that had -back and -back missing, the command 
`qvm-block revert p-2018d:private` was enough.

> > > I remember there was some Saltstack magic to recreate the services vms, 
> > > but could not find anything for R4.0... So I had to revert to R3.2 for 
> > > the time being.
> > 
> > https://www.qubes-os.org/doc/salt/
> > Especially links at the bottom:
> > https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/README.rst
> 
> Thanks. Will also try that tonight.

The way I recreated all sys-* service VMs was:

# You need to unset sys-firewall as netvm for AppVMs
# and unset sys-net as netvm for sys-firewall:
dom0$ qvm-prefs --set  netvm ''
dom0$ qvm-prefs --set sys-firewall netvm ''

# The delete all service VMs qubes:
dom0$ qvm-remove sys-usb
dom0$ qvm-remove sys-firewall
dom0$ qvm-remove sys-net

# Make sure the right salt top files are enabled:
dom0$ sudo qubesctl top.enable qvm.sys-net
dom0$ sudo qubesctl top.enable qvm.sys-firewall
dom0$ sudo qubesctl top.enable qvm.sys-usb
dom0$ sudo qubesctl state.highstate

and that should be all. You have to restore 'sys-firewall' as netvm for all the 
qubes you want networking and thing should be pretty much as they were after 
install. Note that all new service VMs will have different IP address than 
their deceased counterparts, but firewall would be able to cope with that.

Ah! The joy! Now back to R4.0 without massive reinstall.

Thanks Marek, awokd and techg...!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/d343c920-7401-475d-a340-39df7c4b3afa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

2018-04-12 Thread Pablo Di Noto
> > > If, as I suspect, the root cause of your problem is a lack of metadata 
> > > space on pool00; you can confirm this by typing "sudo lvs" into a 
> > > console.  You will then need to figure out a way to enlarge that metadata 
> > > volume.
> > 
> > Yes, you are right, the `pool00` volume metadata was >96% when this 
> > happened. The thing is that the volume metadata was set to a quite small 
> > size after install (96mb on a 46gb pool) and after install was on ~20% 
> > usage. I started to use the system, testing stuff with DispVMs, restoring 
> > my debian templates and some work VMs. After a couple of days of usage the 
> > metadata climbed very little, to 27-28%.
> > 
> > I tried to have a second pool to hold my machines, precisely to avoid 
> > issues with thin provisioning on the pool holding `root` and `swap` and 
> > services vms. But the lack of support for cloning/moving between pools made 
> > that effort moot.
> > 
> > So I `lvextend`ed `pool00` and forgot to properly enlarge it's  
> > `pool00_tmeta` counterpart.
> 
> What sizes you have there?
> For me tmeta is 118MB for a ~450GB pool00. And after few months of usage
> it's still at 33%...

An install on a 60G disk partition had a pool00 of 43G created with a 
pool00_tmeta of 44M (11 extents). Later, the pool00 was extended to 147.7G and 
the pool00_tmeta left as is by mistake. 

The metadata became full, and after that the pool00_tmeta was extended to 300M 
by adding 256M.

> > When doing some more customization, including restoring more larger sized 
> > qubes and cloning/renaming qubes it seems the metadata usage climbed really 
> > fast and hit this bug.
> > 
> > Unfortunately, could not recover from that.
> > 
> > It looks like qubes lvm actions while metadata was full may have corrupted 
> > the metadata somehow, since I could enlarge and repair the thin metadata 
> > from a live cd, but many of the volumes that where in use where never 
> > available again. The -private and -snap for the qubes that were running 
> > (not sure how to discard them) and also all the volumes of the qubes being 
> > restored and services vms are lost ("NOT available" as lvm status)
> 
> You could also try to revert to earlier revision using "qvm-volume
> revert sys-net:private" for example.

Will try that tonight.

> > I remember there was some Saltstack magic to recreate the services vms, but 
> > could not find anything for R4.0... So I had to revert to R3.2 for the time 
> > being.
> 
> https://www.qubes-os.org/doc/salt/
> Especially links at the bottom:
> https://github.com/QubesOS/qubes-mgmt-salt-dom0-virtual-machines/blob/master/README.rst

Thanks. Will also try that tonight. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/cd525562-ead8-4559-9326-c31787b438dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

2018-04-12 Thread Pablo Di Noto
> techg...@gmail.com
> If, as I suspect, the root cause of your problem is a lack of metadata space 
> on pool00; you can confirm this by typing "sudo lvs" into a console.  You 
> will then need to figure out a way to enlarge that metadata volume.

Yes, you are right, the `pool00` volume metadata was >96% when this happened. 
The thing is that the volume metadata was set to a quite small size after 
install (96mb on a 46gb pool) and after install was on ~20% usage. I started to 
use the system, testing stuff with DispVMs, restoring my debian templates and 
some work VMs. After a couple of days of usage the metadata climbed very 
little, to 27-28%.

I tried to have a second pool to hold my machines, precisely to avoid issues 
with thin provisioning on the pool holding `root` and `swap` and services vms. 
But the lack of support for cloning/moving between pools made that effort moot.

So I `lvextend`ed `pool00` and forgot to properly enlarge it's  `pool00_tmeta` 
counterpart.

When doing some more customization, including restoring more larger sized qubes 
and cloning/renaming qubes it seems the metadata usage climbed really fast and 
hit this bug.

Unfortunately, could not recover from that.

It looks like qubes lvm actions while metadata was full may have corrupted the 
metadata somehow, since I could enlarge and repair the thin metadata from a 
live cd, but many of the volumes that where in use where never available again. 
The -private and -snap for the qubes that were running (not sure how to discard 
them) and also all the volumes of the qubes being restored and services vms are 
lost ("NOT available" as lvm status)

I remember there was some Saltstack magic to recreate the services vms, but 
could not find anything for R4.0... So I had to revert to R3.2 for the time 
being.

I will keep the failing install for debugging, or may be able to recover if 
someone can provide any tips about:

- How to recreate sys-net, sys-firewall and sys-usb on a R4.0 system
- how to recover a qube whose -snap volumes are no longer available (I have no 
problem losing these short-term data)

Thanks for pointing to the right direction!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6dbc17a5-6f49-46ac-8e5c-902eae7ee44d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

2018-04-10 Thread Pablo Di Noto
And also, there is possible reason for this to happen as stated 
[here](https://github.com/QubesOS/qubes-issues/issues/3809).

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f2ef3c50-ae7c-49c9-b61c-8294462a7ef6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

2018-04-10 Thread Pablo Di Noto
It seems that there are other users with similar issues: 
https://github.com/QubesOS/qubes-issues/issues/3810
(not 100% sure is the same issue, but I have seen that message from UI tools 
while having this problem)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/499efc2e-92ac-4741-a6e4-5e9264cd8977%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Qubes R4.0 broken by "TypeError: not enough arguments..." for most qvm-* commands

2018-04-10 Thread Pablo Di Noto
Hello,

I am running a Qubes R4.0 install on Thinkpad X250, fully `*-testing` updated, 
and after restoring most of my R3.2 qubes and getting almost ready to switch 
fully to the new version, something happened with `qubesd` or `qubes-db-dom0`.

Most `qvm-*` command fail with:

```
Traceback (most recent call last):
  File "/usr/bin/qvm-start", line 5, in 
sys.exit(main())
  File "/usr/lib/python3.5/site-packages/qubesadmin/tools/qvm_start.py", line 
179, in main
domain.start()
  File "/usr/lib/python3.5/site-packages/qubesadmin/vm/__init__.py", line 100, 
in start
self.qubesd_call(self._method_dest, 'admin.vm.Start')
  File "/usr/lib/python3.5/site-packages/qubesadmin/base.py", line 68, in 
qubesd_call
payload_stream)
  File "/usr/lib/python3.5/site-packages/qubesadmin/app.py", line 483, in 
qubesd_call
return self._parse_qubesd_response(return_data)
  File "/usr/lib/python3.5/site-packages/qubesadmin/base.py", line 102, in 
_parse_qubesd_response
raise exc_class(format_string, *args)
  File "/usr/lib/python3.5/site-packages/qubesadmin/exc.py", line 29, in 
__init__
message_format % tuple(int(d) if d.isdigit() else d for d in args),
TypeError: not enough arguments for format string
```

The first occurrence was when attempting to restore a backup:
```
qubesadmin.backup: Error restoring VM p-android, skipping: not enough arguments 
for format string
```

When the issue started, all qubes that were active were still operating. And 
`qvm-run  ` worked fine on them. Other commands like `qvm-ls` 
work ok.

After a reboot, all ServiceVMs are not starting, so the complete system is 
broken. 

I did some analysis on the traceback and the error seems to be simply that an 
Exception is raised without any data. But I do not know how to enable more 
debugging or provide more specific data.

Tryed to restart `dom0` daemons, look into /var/log/qubes/* and 
/var/log/libvirt/* without getting any clues about what is failing.

Only change from stock install is that I had to `lvextend` the default `pool00` 
volume to have enough disk space, and the extension segment is on a second, 
permanent SSD.

Should I raise an issue?
Any debugging tips?

Cheers,
///Pablo



-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/36e01a27-f55c-436b-adf8-820cd5d7b1fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: [qubes-devel] Re: Request for feedback: 4.9 Kernel

2017-06-01 Thread Pablo Di Noto

> > Experiencing consistently the "no wifi after resume" which was working fine 
> > with 4.4.x
> 
> This can be avoided by adding "iwldvm iwlwifi" line to
> the following file in your WiFi NetVM:
>   /rw/config/suspend-module-blacklist

Thanks! Found the specific thread 
(https://groups.google.com/d/msg/qubes-users/2iu5unw1bzY/zKYLCjduAAAJ) and 
already trying the fix.

> >> 4) General feedback on the 4.9 kernel.
> >
> > Oh, yeah... I have started experiencing quite annoying internet 
> > connectivity issues, very, very difficulty to troubleshot. Symptoms are:
> >
> > - Web browsing fails with ERR_EMPTY_RESPONSE, pages load partially never 
> > reaching some of the content.
> > ...((removed for brevity))
> > It seems pretty repeatable, and would love to provide debugging info, 
> > although I do not know where to look for.
> 
> I, too, encountered this issue and was unable to find
> the cause. Had to revert to 4.4.67-12 kernel. :(

Oh, well. I am not crazy then. :)
Maybe being a generic bug will make it worth debugging.

Cheers,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f8df1a0a-6e40-4538-b1e8-0c2250a62b8d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Thank you to unman and magicadu!

2017-06-01 Thread Pablo Di Noto
Thanks from Argentina, unman and magicadu!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f1d1146b-2b6c-4db7-b764-9dc22dd6acd8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Moving less used templates to secondary storage

2017-02-09 Thread Pablo Di Noto
Hello,

Running 3.2 with XFCE.

My notebook has a small SSD with Qubes boot and root/swap on it, and a larger 
(and slower) SHDD mounted as /var/lib/qubes-add and configured as an additional 
Xen pool.

I am running out of space (and at the same time, losing speed drastically) on 
the SSD, and half of the space is used by fedora-23, debian-8, debian-9 and 
whonix-* templates.

I decided to move the debian-8 and whonix-* templates to the additional pool, 
but cannot make the move be recognized by Qubes (all command line utilities 
obviously cannot find the templates).

Question 1: Is this use-case --having templates on a secondary storage pool-- 
supported?
Question 2: Which is the proper way to move the least used templates? I guess 
qvm-prefs need to reflect the move somehow, but have not been able to deduce 
myself.

Willing to write up docs after done :-)

Cheers,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e8a61aaf-0343-48aa-95ad-d213c9e12a36%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 3.1, Debian Stretch VM: audio not working

2017-02-04 Thread Pablo Di Noto
El viernes, 12 de agosto de 2016, 7:21:16 (UTC-3), RSS escribió:
> On Fri, 12 Aug 2016 00:37:59 -0700
> Andrew David Wong  wrote:
> 
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > On 2016-08-10 04:32, RSS wrote:
> > > Everything should be update, with Qubes stretch "testing" sources
> > > turned on.
> > > 
> > > This has been broken for a while, is it a known problem? If I try
> > > to start it manually with debug turned on, there seems to be zero
> > > useful information:
> > > 
> > > $ pulseaudio --start --log-level=debug -n 
> > > --file=/etc/pulse/qubes-default.pa
> > > 
> > > D: [pulseaudio] conf-parser.c: Parsing configuration file 
> > > '/etc/pulse/client.conf'
> > > 
> > > D: [pulseaudio] conf-parser.c: /etc/pulse/client.conf.d does not
> > > exist, ignoring.
> > > 
> > > E: [pulseaudio] main.c: Daemon startup failed.
> > >   
> > 
> > Yes, this is being tracked here:
> > 
> > https://github.com/QubesOS/qubes-issues/issues/1927
> 
> Cool, and the workaround mentioned there
> 
> sudo ln
> -s /usr/lib/pulse-8.0/modules/module-vchan-sink.so 
> /usr/lib/pulse-9.0/modules/module-vchan-sink.so
> 
> still works like a charm.
> 
> Thanks!

With recent release of Pulseaudio version 10.0, the module is back the wrong 
directory. The same workaround works. See 
https://github.com/QubesOS/qubes-issues/issues/1927#issuecomment-277451087

Cheers,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6e556188-8e86-4f56-a5b0-3bca573bd735%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: HCL Lenovo Thinkpad X250 i3-5010U

2016-12-24 Thread Pablo Di Noto
El 24 dic. 2016 06:28, "thinkpad user" <somelegaldownloadu...@gmail.com>
escribió:

On Friday, March 11, 2016 at 2:45:50 AM UTC+4, Pablo Di Noto wrote:
> So far, everything works as expected

Thanks for sharing info! Have you tested graphics software yet (especially
3d editing/games)? Webcam working?
Have any other issues?


Hello!
Never used with ganes.

Have been using a couple of 3D modelling software (FreeCAD and a
proprietary, licensed version of another I cannot recall) without any
noticeable issue (models worked on where quite simple, by the way, wood
furniture)

Webcam works on any Linux I tried on the X250, and with Qubes and a
"sys-usb" service machine properly configured, sending the webcam to a
"skype-vm" or "webconf-vm" with chrome and audio-plugins worked fine
(Google h hangouts, zoom, even pitiful webex works after fiddling with java)

I noticed that being a two-battery machine, almost all battery applets mess
up their "remaining time" prediction, and cannot gracefully deal with a
battery hot swap: you loose the status on the newly inserted battery, but
that is only a status display problem. Switching batteries without actual
disruption works fine and is the reason I love this model (a second 68+
battery gives me  a solid 12 hours total and I can decide when to take that
extra weight it with me)

Using it with a dock is also supported.
The USB ports appear and stay on the controller that is already in the
sys-usb vm, so docking and undocking is seamless.

Hope it helps.
Regards
///Pablo

--
You received this message because you are subscribed to a topic in the
Google Groups "qubes-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/
topic/qubes-users/4I2rO0tq4Sg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/
msgid/qubes-users/ea6b25ac-780c-4e77-8c97-4f020d6ddbdf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAOJFbN-Mgg_2%2B3cV3PopXPXka-QH0RU_xBBgaf-yLdHm_%2BGnuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes R3.2 on Thinkpad X250: cannot install Windows 7 (hangs on "Starting Windows" at install)

2016-11-21 Thread Pablo Di Noto
El domingo, 20 de noviembre de 2016, 20:11:45 (UTC), Scot Anderson escribió:

> New to Qubes (installed today!), and this is my first post, but I had this 
> same problem on my Thinkpad T420 and have gotten past it. Some light google 
> sleuthing led me to a Proxmox issue that was similar, and they suggested 
> trying a 'cirrus' video card instead of default.
> 
> Digging around in Qubes source, I found you can pass a custom config to 
> qvm-start. I copied the config for the vm to another location (from 
> /var/lib/qubes/vm-templates/win7/win7.conf in my case) and edited the line in 
> domain->devices->video->model and changed the type from 'xen' to 'cirrus'. So 
> the result looked like this:
> 
> 
> 
> Then I started the vm with:
> qvm-start win7 --custom-config=[path to new config]
> 
> This allowed me to get past the install hang. I haven't completed the install 
> yet, so don't know if it'll be necessary once the install is complete.
> 

Great tip, Scot!
Doing that I was able to move on into the install process.

Being a long-time proxmox user, it never occurred to me that look there for 
tips (my understanding is that proxmox is kvm- or lxc-based, and since Qubes is 
trying to move away from qemu-related stuff that sort of things would not apply 
here).

So, for the record, storage pools and specific Lenovo X250 had nothing to do 
with this Windows 7 "no further than glowing logo" issue.

Thanks again!
///Pablo 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f3645941-fb07-49e6-8b31-0f055b2febfc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Qubes R3.2 on Thinkpad X250: cannot install Windows 7 (hangs on "Starting Windows" at install)

2016-11-09 Thread Pablo Di Noto
Hello,

Never had much use for a Windows7 HVM so far.

Months ago, I installed W7 on Qubes just for the sake of testing. Got to the 
point of installing qubes-windows-tools and had some success with it, but never 
used it much (in fact, never activated a license on the resulting W7 install).

Now I want to start from scratch, but cannot make a HVM to go further than 
"Starting Windows" screen on the install phase.

Only changes I recognize on my setup are:
- R3.2 final installed (which included several Xen updates, 4.6 to 4.6.3 IIRC)
- Got a "storage pool" enabled, to use the machine SHDD together with the boot 
SSD.

So far, tried all this:
- several W7 ISO versions (including the ones I successfully used before).
- creating the HVM with 2, 3 and 4gb of memory.
- creating the HVM on my "big storage" pool, the local SHDD, using -P option in 
the qvm-create command
- creating the HVM on the original storage pool, the local boot qubes-dom0-root 
volume, using the GUI to create the machine.
- using debug options on all the attempts, but logs show absolutely nothing 
that I can recognize as error.

Any pointers on what to try next, or how to debug?

Thanks in advance!
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/a8064898-933d-4dd6-93e3-9cefad78e6d1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes on Lenovo Thinkpad X250 Issues

2016-11-09 Thread Pablo Di Noto

> Bump. Its not Qubes specific. Same applies to latest Xen Hypervisor on Ubuntu 
> 16.04.1.
> 
> Any idea what got introduced into Xen between 3.0 and 3.1?

I am using a X250 since last february (installed R3, updated to R3.1 and full 
reinstall of R3.2).

No problems with booting so far.
Let me know if you want to compare BIOS versions, config, etc.

Regards,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/34188e48-ecec-4821-a9a5-a7ff1d008999%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes R3.2, cannot find redshift{-gtk} packages on dom0

2016-10-21 Thread Pablo Di Noto
>
>
>>
> Well, ahem, it turned out that following the advice on
> https://www.qubes-os.org/doc/i3/
> I could install it without any issue.
>
> I swear I tried `qubes-dom0-current-testing` but it seems I did not.
> Sorry for the noise!
>
>
For future reference (including to myself, it seems) you can install
Redshift, (which adjusts the color temperature of your screen according to
your surroundings and may help your eyes hurt less if you are working in
front of the screen at night, as its author states) in plain R3.2 with:

[user@dom0 ~]$ sudo qubes-dom0-update
--enablerepo=qubes-dom0-current-testing redshift redshift-gtk

Cheers,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAOJFbN_f3b35_Li2hUuysHvPnao6nCR0oX%2BR2Wh9XeboZPWj4g%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes R3.2, cannot find redshift{-gtk} packages on dom0

2016-10-21 Thread Pablo Di Noto
>
>
> On Thursday, October 20, 2016 at 3:47:56 AM UTC+2, Pablo Di Noto wrote:
>> > Hello all,
>> >
>> > I have reinstalled R3.2 and want to install Redshift (and its GUI) on
>> dom0 again.
>> > I do not recall how I did it on R3.1, and successive updates.
>> >
>> > I see on a Fedora 23 VM that redshift and redshift-gtk are available in
>> the `updates` repository.
>> >
>> > But cannot find how to access these (or equivalent) repositories on
>> dom0. Used `qubes-dom0-update --enablerepo=XXX` with many different
>> repositories mentioned in FAQs and other posts here with XXX={updates,
>> qubes-dom0-current-testing, qubes-dom0-security-testing,
>> qubes-dom0-unstable, ...} but all return "Unable to find a match".
>> >
>> > What am I missing?
>> >
>>
>> I know how to install redshift but whats the dom0 command to install the
>> redshift-gtk ?
>>
>> sudo yum install redshift-gtk ?
>>
>> tried it and can not find it...
>>
>>
> Well, as I mentioned in my original post, neither `redshift` nor
> `redshift-gtk` seem to be available into the repositories that come
> installed and enabled in Qubes R3.2.
>
> I guess during my successive updates from R3 -> R3.1rcX -> R3.2rcX somehow
> I enabled a testing repository where I found it, but cannot redo the same
> now.
>
> Being a mostly debian/ubuntu habitual, I am not very familiar with the
> latests Fedora packaging. I can grasp the idea on a Fedora 23 vm, but I get
> lost in the dom0 proxy update system (works like a charm, no intention of
> critizicing it).
>
> My eyes miss Redshift, would really appreciate any pointers.
>
> Cheers,
> ///Pablo
>
>
>
>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "qubes-users" group.
>> To unsubscribe from this topic, visit https://groups.google.com/d/to
>> pic/qubes-users/Qi1NqE8raS8/unsubscribe.
>> To unsubscribe from this group and all its topics, send an email to
>> qubes-users+unsubscr...@googlegroups.com.
>> To post to this group, send email to qubes-users@googlegroups.com.
>> To view this discussion on the web visit https://groups.google.com/d/ms
>> gid/qubes-users/9770c041-20de-45ca-87c6-0e3fbf0cf603%40googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>>
>
>
Well, ahem, it turned out that following the advice on
https://www.qubes-os.org/doc/i3/
I could install it without any issue.

I swear I tried `qubes-dom0-current-testing` but it seems I did not.
Sorry for the noise!

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAOJFbN_P5skuKOOKspqNdzHYpNb3y8%3DYFdr0pK5XGX%3DYxfyARg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] [Q] Linux HVM & inter-VM networking

2016-10-05 Thread Pablo Di Noto
El miércoles, 6 de abril de 2016, 5:39:40 (UTC-3), 
li...@mullvad.net escribió:
> On Tuesday, February 9, 2016 at 3:18:41 PM UTC+1, Marek Marczykowski-Górecki 
> wrote:

> 
> On Tue, Feb 09, 2016 at 06:06:47AM -0800, Stefan wrote:
> 
> > Am Dienstag, 9. Februar 2016 14:41:57 UTC+1 schrieb Marek 
> 
> > Marczykowski-Górecki:
> 
> >  
> 
> > > > Solution: Qubes 3.1 disables ProxyARP by default; enable it on your 
> > > > Firewall VM: 
> 
> > > > echo 1 > /proc/sys/net/ipv4/conf/$DEST_DEV/proxy_arp 
> 
> > > > where DEST_DEV is the device name of your target VM. 
> 
> > > > That did the trick in my case. 
> 
> > > Can you describe exactly your setup, including network configuration in 
> 
> > > Windows? "route print" command output from there would be useful. 
> 
> > With pleasure :-)
> > Linux AppVM (10.137.3.15), based on the fedora-23 template, no 
> > modifications to the AppVM firewall
> > Windows HVM with Windows 7 (10.137.3.13), no Qubes Tools. Configured as 
> > home network, firewall disabled (though I don't think this is any longer 
> > necessary).
> 
> > Both connected to the same FirewallVM (fedora-23 template).
> > Tried to establish a connection from Linux to Windows by following 
> 
> > https://www.qubes-os.org/doc/qubes-firewall/:
> 
> > sudo iptables -I FORWARD 2 -s 10.137.3.15 -d 10.137.3.13 -j ACCEPT
> > 
> > pinging didn't work, so I started digging… this is the routing of the 
> > FirewallVM:
> 
> > $ route -n
> 
> > Kernel IP routing table
> 
> > Destination     Gateway         Genmask         Flags Metric Ref    Use 
> > Iface
> > 0.0.0.0         10.137.2.1      0.0.0.0         UG    0      0        0 eth0
> > 10.137.2.1      0.0.0.0         255.255.255.255 UH    0      0        0 eth0
> > 10.137.3.13     0.0.0.0         255.255.255.255 UH    32744  0        0 
> > vif8.0
> > 10.137.3.13     0.0.0.0         255.255.255.255 UH    32745  0        0 
> > vif7.0
> > 10.137.3.15     0.0.0.0         255.255.255.255 UH    32747  0        0 
> > vif5.0
> 
> > Note that the Windows VM has two interfaces (for whatever reason).
> 
> > Sniffing with Wireshark on vif7.0 showed no traffic. vif8.0 revealed that:
> > - the icmp requests arrive on the interface
> > - Windows sends ARP requests for 10.137.3.15
> > - ...but gets no ARP response
> 
> > Manually adding an ARP entry didn't do the trick. Windows now sent ping 
> > replies (visible on vif8.0), but they didn't reach the Linux AppVM.
> > 
> > Enabling proxy_arp for vif8.0 solved the problem.
> > 
> > 
> > Enclosed is a screenshot of Windows' "route print" (sorry, no Qubes Tools, 
> > no copy-paste).
> > 
> > 
> > Hope this helps :-)
> 
> Try setting netmask 255.255.255.255 in Windows. If it still doesn't help
> perhaps it would require additional route entry to 10.137.3.1 directly
> through emulated ethernet. But in such a case, enabling proxy_arp is
> just the simples solution.
> 
> Best Regards,
> Marek Marczykowski-Górecki
> Invisible Things Lab
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> 
> I have the same problem between an Ubuntu 14.04 HVM and a debian-8 AppVM. No 
> arp responses sent to the HVM. I have the same setup as Thomas with a 
> 255.255.255.0 mask in the HVM. Setting it to 255.255.255.255 didn't help 
> (Because now my gw is outside my local network?)
> 
> I have tried basing my ProxyVM on both fedora-23-minimal and fedora-23, same 
> results.
> 
> I could temporarily make it work by manually adding an arp entry in the HVM:
> $ sudo arp -s  
> 
> But after finding this thread I solved it by activating proxy arp in 
> /rw/config/qubes-firewall-user-script on the ProxyVM:
> # Activate proxy arp
> for i in /proc/sys/net/ipv4/conf/vif*/proxy_arp; do
>     echo 1 > $i
> done 
> 
> Are there any security implications of activating proxy arp? Why was it 
> turned off (everything worked as expected in Qubes R3.0)
> 
> /Linus

I have just ran into this issue while using Qubes R3.2, and a Ubuntu HVM.
Should we include this instructions on the 
https://www.qubes-os.org/doc/qubes-firewall/ page?
Somehow, it took me a whole day to get to this post. I just wanted to access a 
new HVM thru SSH.

I can add this info into it, if there is editing available.
Regards,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/93543d11-ff74-495e-ae59-4415f0055c9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Wrong timezone in VMs: where the value for qubesdb-read /qubes-timezone comes from?

2016-08-31 Thread Pablo Di Noto
El miércoles, 31 de agosto de 2016, 13:02:06 (UTC), Andrew David Wong escribió:
> 
> On 2016-08-31 05:42, Pablo Di Noto wrote:
> > El miércoles, 31 de agosto de 2016, 12:26:42 (UTC), Andrew David Wong 
> > escribió:
> > 
> >> On 2016-08-31 04:48, Pablo Di Noto wrote:
> >>> Hello,
> >>> 
> >>> Somewhere along the update from 3.1 to 3.2rc1 I started to have all my 
> >>> VMs take UTC as their timezone.
> >>> 
> >>> dom0 has the correct "America/Argentina/Cordoba" timezone, but all VMs 
> >>> get incorrectly set to "Argentina/Cordoba", which does not exists thus 
> >>> leaving them at UTC.
> >>> 
> >>> I know may have manually set somehow the wrong timezone (without the 
> >>> required "America/" prefix) at install or update. Now all my templates 
> >>> get set to "Argentina/Cordoba", which is the value they get from 
> >>> "qubesdb-read /qubes-timezone" at every boot by qubes-sysinit.sh
> >>> script.
> >>> 
> >>> I cannot figure out where that values comes from and how to fix it.
> >>> 
> >>> Thanks in advance, ///Pablo
> >>> 
> >> 
> >> It might be worth trying to set the locale in your TemplateVM(s). For 
> >> example, these commands should work on fedora-23 (and some other
> >> distros):
> >> 
> >> To display your currently set locale:
> >> 
> >> $ locale
> >> 
> >> To set a locale:
> >> 
> >> # localectl set-locale 
> >> 
> >> For a list of available locales:
> >> 
> >> $ localectl list-locales
> >> 
> > 
> > Thanks for the suggestion. In fact, something similar is what I use as 
> > workaround into the browsing VMs.
> > 
> > The drawback is that I have to set the correct timezone for each VM upon 
> > booting, each time, as the setting will be overriden at next boot by the
> > init script.
> > 
> > Regards, ///Pablo
> > 
> 
> Two options:
> 
> 1. Change the locale in the TemplateVM instead of the AppVM so that the
> overriding value is the desired one.

There is no difference setting it at the TemplateVM, as it is also overridden 
by the script there.

> 2. Add the command to change to the desired locale to /rw/config/rc.local (in
> the AppVM), then make that file executable (chmod +x). Every command in that
> file is executed as root each time the AppVM is started.

Thanks Andrew!

This works, but still makes you reset the timezone on each TemplateVM when 
traveling. Not a big deal. I will keep trying to find the root cause of this, 
albeit to understand the mechanics behind the scenes.

Regards,
///Pablo

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/57658dc1-7e46-48ca-a988-c9e57c92e280%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.