Re: [qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)

2019-08-15 Thread *Null* **
oh I am dumb, perhaps try logging in with your template vm, do the key 
exchange, and then shut it down. It may stick into the appvm?

On Thursday, August 15, 2019 at 11:15:46 AM UTC-7, 799 wrote:
>
> Hello,
>
> *Null* ** > schrieb am Do., 15. Aug. 
> 2019, 19:12:
>
>> OCC commands:
>>
>>
>> https://docs.nextcloud.com/server/16/admin_manual/configuration_server/occ_command.html#user-commands-label
>>  (...)
>
>
> Now I understand what you've meant, regarding the movement of directories. 
> This was related to running a Nextcloud Server within Qubes OS.
> In my case I am connected from an AppVM (Qubes OS) to an external 
> Nextcloud-Server (not running Qubes OS).
>
> As all Client-settings _should_ be safe in an AppVM I don't understand why 
> I need to login after the first boot of the AppVM and why even after login 
> in, the synchronization is not working again.
>
> [799]
>

-- 
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/899c309f-be2a-47c9-a1e9-b83061518976%40googlegroups.com.


Re: [qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)

2019-08-15 Thread *Null* **
Oh yeah /home is saved too... I thought just /rw. It is advised on the 
nextcloud hardening guide to not keep it in the default location and on my 
setup I had to move it anyways because of how the machine is set up.

-- 
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/274990d8-a2fa-4854-bebb-55c18557fb9d%40googlegroups.com.


Re: [qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)

2019-08-15 Thread *Null* **
OCC commands:

https://docs.nextcloud.com/server/16/admin_manual/configuration_server/occ_command.html#user-commands-label

In qubes you have to specify the file path to occ(in the docs it lets you call 
occ by itself).
So for a typical fedora/apache/nc install in the template you would enter:

Sudo -u httpd(or apache) php /usr/share/nextcloud/occ [enter commands]

OCC is your main way of administering nextcloud in qubes so that link will help.

Qubes appvms do not keep anything outside of /rw so you would need to migrate 
the storage folder into /rw 
(https://help.nextcloud.com/t/howto-change-move-data-directory-after-installation/17170)

Or you can declare certian folders or files to be persistent. 
https://www.qubes-os.org/doc/bind-dirs/

This is done in the appvm. Dont designate all of nextcloud to be persistent or 
if someone hacks the nextcloud appvm its there forever. It is bad enough you 
are doing it to the file folder.

I assume you installed nextcloud in the template and set up an admin account in 
the process. So when you fire up the appvm anything you do in there will be 
erased until you add your users via occ in the template and preserve the file 
folder.

Once you do all that it will work fine from your home network, exposing it to 
the world is a bit of a pain and introduces an attack vector obviously.

-- 
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/b7f8b6a3-1961-46a4-a095-5e987188f93f%40googlegroups.com.


[qubes-users] How to upgrade fedora versions, but exclude certian apps

2019-08-15 Thread *Null* **
I upgraded a fedora minimal based template using the qubes docs guide but one 
program i was using gor downgraded in the process. Manually upgrading it is a 
huge pain. 

Is there an option to exclude a certian app from the process?

-- 
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/e64f3e12-8746-4963-8ee3-a071398d9db6%40googlegroups.com.


[qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)

2019-08-15 Thread *Null* **
Sorry my initial reply was the wrong answer.

To set up a login that is persistant you need to do it in the template with the 
occ commands. Any user made in the appvm will not survive a reboot.

The nextcloud storage area needs to be made persistant using the 
qubes-bind-dirs directory in the appvm, the qubes docs cover that.

I am able to stay logged in with the nextcloud app and sync via webdav between 
reboots in this manner.

Are you also trying to sync other appvms?

-- 
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/5787f646-e605-453e-9522-b4205b834377%40googlegroups.com.


[qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)

2019-08-15 Thread *Null* **
Youve got to set up your user names in the template. So fire up httpd in your 
template and use the occ commands to add users. Its inconvienent, but the appvm 
non persistance is the secuity feature that is also preventing anyone from 
embedding anything too nasty in your system.

I have tried to find where specifically user data is stored if you really 
wanted to allow users to add themselves while the server runs and between 
reboots, but I recall not finding out much. This has been asked about on the NC 
forums as well.

Youve also got to set up the storage area to be persistant between boots. This 
is easier to make non persistant. Follow the NC hardening guide to move the 
folder somewhere else, and then use qubes-bind-dirs to make that folder 
persistant. You would need to do the move in the template, but set up the 
bind-dirs in the app.

-- 
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/d1f13c0d-d849-4d65-b453-4d04d969962b%40googlegroups.com.


[qubes-users] Haproxy on sys-net possible?

2019-08-13 Thread *Null* **
Would installing haproxy on sys-net compromise the standard qubes firewall 
scheme?

I know there is an elevated risk in accepting incoming requests. But currently 
I have port forwarding enabled to expose certian services to the outside world, 
and my understanding of port forwarding is that it is a more literal 'hole' in 
the firewall.

What I have are two or more servers running in their own respective qubes. I 
was thinking the incoming connections would hit the haproxy frontend in 
sys-net, authenticate the request, and forward it to the respective service 
backend via sys-firwall etc...

If haproxy authenticates it could decrypt the ssl connection and forward it as 
a normal packet, preventing a bad ssl punching through all of the qubes 
security layers.
Or perhaps I could allow ssl passthrough and simply prevent any other 
connections out of the service qube and into the qube system...

Thoughts? Suggestions?

-- 
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/8b9c4731-6912-4802-95b8-b679e89147fc%40googlegroups.com.


Re: [qubes-users] Cannot reach FreeBSD from Qube but can reach Qube from FreeBSD

2019-07-14 Thread *Null* **
On Sunday, July 14, 2019 at 7:21:08 AM UTC-7, unman wrote:
> On Sat, Jul 13, 2019 at 02:09:14PM -0700, *Null* ** wrote:
> > I have a FreeBSD HVM connected to a firewall VM. I also have a Fedora Qube 
> > connected to the same firewall VM. Networking between these was enabled 
> > using the iptables instructions from the Qubes documentation.
> > 
> > I can ping and access resources on the Fedora Qube from FreeBSD(I can 
> > transfer files to and download files from the Fedora VM).
> > 
> > However, I cannot do the same from the Fedora VM. It can ping the firewall, 
> > but not FreeBSD. Nor can it access resources on the FreeBSD system.
> > 
> > This confuses me because I would assume file transfer(from bsd to fedora) 
> > implies there is some bi-directional communication. But it seems to only 
> > work when initiated from one direction(from BSD).
> > 
> > All VMs can connect to the internet, FreeBSD can ping any vm, other VMs can 
> > ping other qubes based vms, but cannot ping FreeBSD.
> > 
> > What else must be done?
> > 
> This works as advertised.
> Can you check on your HVM that you are allowing incoming requests?
> That's the obvious explanation for the scenario you have.

Ah, I had set ipv4 accept any, figuring that would be fine. But I wrote another 
for icmp and it worked to ping it.
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/aa390f94-9d3b-4cae-92b0-a734e6290d5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Cannot reach FreeBSD from Qube but can reach Qube from FreeBSD

2019-07-13 Thread *Null* **
I have a FreeBSD HVM connected to a firewall VM. I also have a Fedora Qube 
connected to the same firewall VM. Networking between these was enabled using 
the iptables instructions from the Qubes documentation.

I can ping and access resources on the Fedora Qube from FreeBSD(I can transfer 
files to and download files from the Fedora VM).

However, I cannot do the same from the Fedora VM. It can ping the firewall, but 
not FreeBSD. Nor can it access resources on the FreeBSD system.

This confuses me because I would assume file transfer(from bsd to fedora) 
implies there is some bi-directional communication. But it seems to only work 
when initiated from one direction(from BSD).

All VMs can connect to the internet, FreeBSD can ping any vm, other VMs can 
ping other qubes based vms, but cannot ping FreeBSD.

What else must be done?

-- 
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/87057d29-56b8-4819-9306-4a37528ba2ea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.