Re: [qubes-users] feature request: qvm-print command
On Tue, May 19, 2020 at 11:14:45AM +0200, haaber wrote: > Hello there, I was thinking about the usefulness of a qvm-print command > that takes an input file, sends it to the "printing-VM" (defined in some > config file), and launches there a document viewer (defined in the > config file) in order to control parameters like duplexing, grayscale..) > or just runs plain "lp". After succesful printing it should clean up & > remove the file in the QubesIncoming folder. if your printer is not locally connected, you can just set up a dvm for printing, then use open-in-dvm. for a local printer, i would aim for a qubes-trusted-pdf hybrid that does content neutralization in a dvm, and a printing adapter vm that only accepts pixel streams and does minimal adaption for printjob parameters (duplexing,...). -- 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/20200519094325.GP1079%40priv-mua.
[qubes-users] feature request: qvm-print command
Hello there, I was thinking about the usefulness of a qvm-print command that takes an input file, sends it to the "printing-VM" (defined in some config file), and launches there a document viewer (defined in the config file) in order to control parameters like duplexing, grayscale..) or just runs plain "lp". After succesful printing it should clean up & remove the file in the QubesIncoming folder. Did someone construct such a thing already? Could be a nice feature, to my point of view. Bernhard -- 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/7b5d0139-51da-8718-f157-7cd6dc7d988d%40web.de.
Re: [qubes-users] feature request
On Saturday, January 25, 2020 at 2:53:53 PM UTC+1, Chris Laprise wrote: > > On 1/25/20 7:15 AM, haaber wrote: > > Hello, I have several virtual screens; I guess many user have. Is it > > possible to reserve one of them exclusively for dom0 and templateVM > > terminals -sort of a separated "admin screen"- to avoid other > > appVM-windows popping up and being able to capture input from keyboard? > >Bernhard > > > > KDE lets you confine windows to certain screens or virtual desktops > under System Settings / Desktop Management / Window Rules. You can > specify how it matches the window, such as pattern matching on the > window title. > > For example, if you set Window Title to 'Regular expression' and the > text to '^\[personal', then under Size/Position select 'Desktop', 'Apply > Initially' and 'Desktop 2' ... that will make windows from any VM > beginning with "personal" open only on Desktop 2. You can also use > 'Force' instead of 'Apply Initially' and that will prevent you from > moving those windows to a different desktop. > > I think the regular expression matching is probably powerful enough to > do what you want. For example, a rule for any window title NOT beginning > with '[' and NOT having also ']' would be a dom0 window. Another rule > could have the names of all your templates. > > -- > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > Thanks for pointing that out. Currently trying KDE in Qubes 4.1 beta, and it's quite a change from xfce 4.14 even (which was already preferable to previous iterations). -- 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/de32ccc0-ca2c-4c52-8479-153731e060aa%40googlegroups.com.
VS: [qubes-users] feature request
DWM can do this for you.it has inbuilt mechanims to Lock app windows to separate tags (Virtual desktops). Also you can define on which monitor this tags is and where you want to Lock it. I'm using dwm on my everyday qubes thinkpads and it works great, all application windows goes there where I want them to go and they don't mess my currently active "window". Lähetetty Jolla Sailfish -älypuhelimestani. Alkuperäinen viesti Lähettäjä: haaber Lähetetty: lauantaina 25. tammikuuta 2020 13.15 Päättymisaika: qubes-users; Andrew David Wong Aihe: [qubes-users] feature request Hello, I have several virtual screens; I guess many user have. Is it possible to reserve one of them exclusively for dom0 and templateVM terminals -sort of a separated "admin screen"- to avoid other appVM-windows popping up and being able to capture input from keyboard? Bernhard -- 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/1c4a6f80-6f85-f1c1-4995-dc5f0cb0ab2b%40web.de. -- 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/20200126064945.4661302.71896.16030%40gmail.com.
Re: [qubes-users] feature request
January 25, 2020 1:53 PM, "Chris Laprise" wrote: > On 1/25/20 7:15 AM, haaber wrote: > >> Hello, I have several virtual screens; I guess many user have. Is it >> possible to reserve one of them exclusively for dom0 and templateVM >> terminals -sort of a separated "admin screen"- to avoid other >> appVM-windows popping up and being able to capture input from keyboard? >> Bernhard > > KDE lets you confine windows to certain screens or virtual desktops > under System Settings / Desktop Management / Window Rules. You can > specify how it matches the window, such as pattern matching on the > window title. > > For example, if you set Window Title to 'Regular expression' and the > text to '^\[personal', then under Size/Position select 'Desktop', 'Apply > Initially' and 'Desktop 2' ... that will make windows from any VM > beginning with "personal" open only on Desktop 2. You can also use > 'Force' instead of 'Apply Initially' and that will prevent you from > moving those windows to a different desktop. > > I think the regular expression matching is probably powerful enough to > do what you want. For example, a rule for any window title NOT beginning > with '[' and NOT having also ']' would be a dom0 window. Another rule > could have the names of all your templates. 1) At least on my machine (XFCE), dom0 windows start with "[Dom0]". But I get your point. 2) The "[]" part of the window title is not actually part of the WM_NAME property. It's the WM_CLIENT_MACHINE property. But as long as you can match on that, it makes it even easier to write rules. You can see it with xprop: [user@dom0 ~]$ xprop -id 0x1614d7d | grep -i 'Dom0' WM_CLIENT_MACHINE(STRING) = "dom0" WM_ICON_NAME(STRING) = "Terminal - user@dom0:~" _NET_WM_ICON_NAME(UTF8_STRING) = "Terminal - user@dom0:~" WM_NAME(STRING) = "Terminal - user@dom0:~" _NET_WM_NAME(UTF8_STRING) = "Terminal - user@dom0:~" Interestingly, I don't actually see a property equal to the full titlebar of the window, so I guess that's constructed by the window manager. -- 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/ff15a51104bd134e89d4a4ae32a4e89f%40disroot.org.
Re: [qubes-users] feature request
On 1/25/20 7:15 AM, haaber wrote: Hello, I have several virtual screens; I guess many user have. Is it possible to reserve one of them exclusively for dom0 and templateVM terminals -sort of a separated "admin screen"- to avoid other appVM-windows popping up and being able to capture input from keyboard? Bernhard KDE lets you confine windows to certain screens or virtual desktops under System Settings / Desktop Management / Window Rules. You can specify how it matches the window, such as pattern matching on the window title. For example, if you set Window Title to 'Regular expression' and the text to '^\[personal', then under Size/Position select 'Desktop', 'Apply Initially' and 'Desktop 2' ... that will make windows from any VM beginning with "personal" open only on Desktop 2. You can also use 'Force' instead of 'Apply Initially' and that will prevent you from moving those windows to a different desktop. I think the regular expression matching is probably powerful enough to do what you want. For example, a rule for any window title NOT beginning with '[' and NOT having also ']' would be a dom0 window. Another rule could have the names of all your templates. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 -- 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/6b8a41fd-8abf-06ff-b70b-82fba2219478%40posteo.net.
Re: [qubes-users] feature request
January 25, 2020 1:40 PM, "Claudia" wrote: > January 25, 2020 11:58 AM, brendan.h...@gmail.com wrote: > >> I think some window managers allow one to pin certain applications to >> particular virtual desktops. >> But those aren’t really security features, more just window manager tricks >> to help users organize >> windows. >> >> My preference would be something along the lines of support for allowing >> multiple local x-servers >> in dom0 [or in future displayVM(s)] and options to allow mapping of dom0 and >> guests/domUs each or >> in groups to a particular x-server. Certain features would not work across >> x-windows sessions, e.g. >> inter vm copy/paste. One could also enforce it at the qubes policy level >> (e.g. no qvm-copy either). >> >> Useful if you want to reduce the chances of mistakenly leaking data across >> client work and/or >> personas. > > It seems to me like you could almost do this today, by starting another X on > another TTY each with > its own qubes_guid, optionally as different user. Each guid could probably be > patched* to listen on > different vchan "ports" (libvchan_[server|client]_init()), however I don't > think the vchan > infrastructure has any kind of real access control below the VM level. So in > order to really > isolate them on the dom0 side, you'd probably have to run a separate > xenstored for each X server, > so that you could control which server has access to the xenstore device > node. But I don't think > that would really be necessary if you're just trying to prevent accidental > leakage by the user. > > (*Currently it appears to use a hardcoded vchan "port" of 6000. See > qubes-gui-daemon/xside.c, and > qubes-gui-agent-linux/gui-agent/vmside.c. Note that gui-agent (domU) is > actually the server, and > guid (dom0) is actually the client.) > Actually, what was I thinking. If the VM is the server and dom0 guid is the client, they wouldn't have to use different ports, assuming the vchan semantics works like TCP/IP. You'd just have to come up with some way to control which domains can send MSG_CREATE requests to which instance of guid. -- 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/ef06df5178ac410b480ddae583002b04%40disroot.org.
Re: [qubes-users] feature request
January 25, 2020 11:58 AM, brendan.h...@gmail.com wrote: > I think some window managers allow one to pin certain applications to > particular virtual desktops. > But those aren’t really security features, more just window manager tricks to > help users organize > windows. > > My preference would be something along the lines of support for allowing > multiple local x-servers > in dom0 [or in future displayVM(s)] and options to allow mapping of dom0 and > guests/domUs each or > in groups to a particular x-server. Certain features would not work across > x-windows sessions, e.g. > inter vm copy/paste. One could also enforce it at the qubes policy level > (e.g. no qvm-copy either). > > Useful if you want to reduce the chances of mistakenly leaking data across > client work and/or > personas. It seems to me like you could almost do this today, by starting another X on another TTY each with its own qubes_guid, optionally as different user. Each guid could probably be patched* to listen on different vchan "ports" (libvchan_[server|client]_init()), however I don't think the vchan infrastructure has any kind of real access control below the VM level. So in order to really isolate them on the dom0 side, you'd probably have to run a separate xenstored for each X server, so that you could control which server has access to the xenstore device node. But I don't think that would really be necessary if you're just trying to prevent accidental leakage by the user. (*Currently it appears to use a hardcoded vchan "port" of 6000. See qubes-gui-daemon/xside.c, and qubes-gui-agent-linux/gui-agent/vmside.c. Note that gui-agent (domU) is actually the server, and guid (dom0) is actually the client.) Then, optionally you could implement some sort of policy to enforce which VMs are allowed to connect to which guid. Whether as a qubes-rpc policy of some sort, within guid, or just a simple X hook/script using the _NET_QUBESVM window property. https://www.qubes-os.org/doc/gui/ https://www.cs.uic.edu/~xzhang/vchan/ https://github.com/QubesOS/qubes-core-vchan-xen https://github.com/QubesOS/qubes-gui-daemon PS: I can't believe the devs are actually thinking about rolling out GUI domains by default in 4.1. It's hard enough to get Qubes running on a given machine as it is now, let alone the fact that VGA passthru is a total crapshoot even under the best conditions. I still can't even get sys-usb to work without corrupting memory space of my VGA controller and SATA controller. -- 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/30823052eccdc181ca9a0774fc3cd678%40disroot.org.
[qubes-users] feature request
I think some window managers allow one to pin certain applications to particular virtual desktops. But those aren’t really security features, more just window manager tricks to help users organize windows. My preference would be something along the lines of support for allowing multiple local x-servers in dom0 [or in future displayVM(s)] and options to allow mapping of dom0 and guests/domUs each or in groups to a particular x-server. Certain features would not work across x-windows sessions, e.g. inter vm copy/paste. One could also enforce it at the qubes policy level (e.g. no qvm-copy either). Useful if you want to reduce the chances of mistakenly leaking data across client work and/or personas. B -- 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/fa793038-32f5-4891-bb70-3699f6ba88c8%40googlegroups.com.
[qubes-users] feature request
Hello, I have several virtual screens; I guess many user have. Is it possible to reserve one of them exclusively for dom0 and templateVM terminals -sort of a separated "admin screen"- to avoid other appVM-windows popping up and being able to capture input from keyboard? Bernhard -- 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/1c4a6f80-6f85-f1c1-4995-dc5f0cb0ab2b%40web.de.
Re: [qubes-users] Feature request
January 5, 2020 7:50 PM, "Franz" <169...@gmail.com> wrote: > May be it already somehow exists and I am not aware of it, but it would be > very interesting to be > able to save backup settings, that is a list of VMs that contain your current > ordinary activity and > you want to backup more often and fast. > > I mean not everything which in my case is over 250gb, not only vaultVM, which > is easy to set, but > lacking other important VMs. > > Rather being able to save a list of perhaps 5-7 more important VMs so that > they are ready for a > fast backup. > > I know there is a CLI that does just that and once even wrote a script for > that, but I am never > sure it still works as intended over so many Qubes upgrades and after every > new Qubes installation > all my scripts are moved from home to elsewhere for some reasons that do not > understand yet. > > So backup is important and any incentive to win backup lazyness is worth > every effort, particularly > because automating Qubes backups is impossible or extremely difficult. > > Is it complicated to add this "save backup setting" to the GUI? > Best Isn't that sort of what "Qube Settings > Basic > Include in backups by default" does? -- 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/08ab9bda08ab38dc0a70263986dcafaf%40disroot.org.
[qubes-users] Feature request
May be it already somehow exists and I am not aware of it, but it would be very interesting to be able to save backup settings, that is a list of VMs that contain your current ordinary activity and you want to backup more often and fast. I mean not everything which in my case is over 250gb, not only vaultVM, which is easy to set, but lacking other important VMs. Rather being able to save a list of perhaps 5-7 more important VMs so that they are ready for a fast backup. I know there is a CLI that does just that and once even wrote a script for that, but I am never sure it still works as intended over so many Qubes upgrades and after every new Qubes installation all my scripts are moved from home to elsewhere for some reasons that do not understand yet. So backup is important and any incentive to win backup lazyness is worth every effort, particularly because automating Qubes backups is impossible or extremely difficult. Is it complicated to add this "save backup setting" to the GUI? Best -- 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/CAPzH-qDNAW9rDge7SsAjBXdPbBfS0mGz03tdmbZ3RJY7XM5btw%40mail.gmail.com.
Re: [qubes-users] Feature request: "HDD Airbag" analog
i see. well, at least helping info on how one can implement this. the idea is not only to have one device for multiple tasks. large SSDs are still not so affordable. regarding practical scenarios for things like 2x2 TB HDDs: local Wikipedia dump. or/and huge Squid cache. imo, it is better to use local storage than online, even if TOR is used. local KBs like Wikipedia means almost 100% no one can trace what user researching and for how long, assuming HW and system has no backdoors to net ofrourse. low security settings of many TOR nodes turning TOR usage into a joke, not mention other known attacks. i recall news article about 3 or more governments pursuing readers of wikileaks. imo its impossible for observer to determine which articles person is reading and when (on airgaped PC), by only having fact of person's monthly wikipedia dump downloads (few hundred of gigabytes in compressed state). by observer right now i mean nonhuman software observers, active 24/7/366, having access to ISP traffic and possibly to target KB server via backdoors. of course this is more like anonymity than security matter. On 16/03/2017 03:39, Andrew David Wong wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-03-15 13:11, thinkpad user wrote: Feature request: "HDD Airbag" analog overview: https://support.lenovo.com/nl/en/solutions/ht003517 list of supported devices: http://support.lenovo.com/nl/en/downloads/ds015000 is it possible to add this feature to Qubes? or atleast provide some interface to poweroff/park HDD? yes, Qubes requires SSD for good operation, but imo most users like to have SSD + large HDD for media or other content. i believe qubes can be really friendly for not so geeky user, by having such features or atleast providing support so user could write such soft. Realistically, the probability of Qubes implementing this is approximately zero, IMHO. (Not Qubes-specific, not security-critical, already not enough time/resources to pursue actual Qubes goals, missing expertise, world moving away from HDDs, etc.) It should be implemented somewhere upstream, if anywhere. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYydC5AAoJENtN07w5UDAw+D4QAIUQouwKMye7CeIuUeW9VGpY CGLCJuvVTBIdAYugZ/EuA6zojz0p0/xMmZEvLcTwrabf9Mbw5IrtotWcxVeZIjE/ n78nWfNp6Z4hrr3RdoUr4Go7svJ2WCkiPrzv2f6sC7LEwF3GEK1ZZIjAODOabFos yc9BwsovthNCvf+6eTnljMPVq0Om6jiCLX+PmDvxm8z1rFxRCOnFFWqKTUpmIHW5 k/Z9z6u89zoJ1IyT9I/x0XIJH2EpZTMbKFcQf/1m59UCcTBdckcDhdaYKdBHDXFn m2CW1knetBta3ubocd5rKn6DR6SwYFJWxa7ZPIwNs//7WT47qHZHu/2SsBukuI3F qZxThA1GHVbVKDXLYR49VAtQVRzzDbK6jjgZvwRLHilaGh41r6klX8Af019hHfRk eYEDK8ngkNosT+ZsgqhxDNOh+viEONOI0StCwKbUw+y7QRhzuadnD4V1dba4ece9 I360QOavzxR8c0ECnwP0ry2dI6TM+6+ru1UMsP0om37l86g/mxd3QBd/6XkIgbjI 2O7Gs8MMZOHkCjwIrZF0aukCrlSEIhOYMc627l941Gk36b8JSDGALgtpXgY5rk7i lXrve4aZd/TCAcnoHR3pEME3/iVuvJ0F4rvM29v35kLueC2PhCiyejTRFJI5TVIa BOVvACwZMHDCefLcivGt =70kE -END PGP SIGNATURE- -- 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/650a89fe-353a-717a-6248-4952952cb50f%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Feature request: "HDD Airbag" analog
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2017-03-15 13:11, thinkpad user wrote: > Feature request: "HDD Airbag" analog > > overview: https://support.lenovo.com/nl/en/solutions/ht003517 list > of supported devices: > http://support.lenovo.com/nl/en/downloads/ds015000 > > is it possible to add this feature to Qubes? or atleast provide > some interface to poweroff/park HDD? yes, Qubes requires SSD for > good operation, but imo most users like to have SSD + large HDD for > media or other content. i believe qubes can be really friendly for > not so geeky user, by having such features or atleast providing > support so user could write such soft. > Realistically, the probability of Qubes implementing this is approximately zero, IMHO. (Not Qubes-specific, not security-critical, already not enough time/resources to pursue actual Qubes goals, missing expertise, world moving away from HDDs, etc.) It should be implemented somewhere upstream, if anywhere. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYydC5AAoJENtN07w5UDAw+D4QAIUQouwKMye7CeIuUeW9VGpY CGLCJuvVTBIdAYugZ/EuA6zojz0p0/xMmZEvLcTwrabf9Mbw5IrtotWcxVeZIjE/ n78nWfNp6Z4hrr3RdoUr4Go7svJ2WCkiPrzv2f6sC7LEwF3GEK1ZZIjAODOabFos yc9BwsovthNCvf+6eTnljMPVq0Om6jiCLX+PmDvxm8z1rFxRCOnFFWqKTUpmIHW5 k/Z9z6u89zoJ1IyT9I/x0XIJH2EpZTMbKFcQf/1m59UCcTBdckcDhdaYKdBHDXFn m2CW1knetBta3ubocd5rKn6DR6SwYFJWxa7ZPIwNs//7WT47qHZHu/2SsBukuI3F qZxThA1GHVbVKDXLYR49VAtQVRzzDbK6jjgZvwRLHilaGh41r6klX8Af019hHfRk eYEDK8ngkNosT+ZsgqhxDNOh+viEONOI0StCwKbUw+y7QRhzuadnD4V1dba4ece9 I360QOavzxR8c0ECnwP0ry2dI6TM+6+ru1UMsP0om37l86g/mxd3QBd/6XkIgbjI 2O7Gs8MMZOHkCjwIrZF0aukCrlSEIhOYMc627l941Gk36b8JSDGALgtpXgY5rk7i lXrve4aZd/TCAcnoHR3pEME3/iVuvJ0F4rvM29v35kLueC2PhCiyejTRFJI5TVIa BOVvACwZMHDCefLcivGt =70kE -END PGP SIGNATURE- -- 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/4d7edb21-d575-3676-3918-08887e810c7f%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Feature request: "HDD Airbag" analog
Feature request: "HDD Airbag" analog overview: https://support.lenovo.com/nl/en/solutions/ht003517 list of supported devices: http://support.lenovo.com/nl/en/downloads/ds015000 is it possible to add this feature to Qubes? or atleast provide some interface to poweroff/park HDD? yes, Qubes requires SSD for good operation, but imo most users like to have SSD + large HDD for media or other content. i believe qubes can be really friendly for not so geeky user, by having such features or atleast providing support so user could write such soft. -- 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/16be7dee-54e1-404a-9e42-581fba972bb8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
Am 10.11.2016 um 12:43 schrieb Eva Star: >> I hope I'm not too offtopic but a gui option to shut down multiple vms at >> once would be cool. > `qvm-shutdown --all --wait` -- will shutdown all VMs (if it helps) Multiple, not all. Select multipel lines and then get a pop-up option "shut these down". Or "qvm-shutdown --class=Template --all". Achim -- 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/524504aa-61af-72ca-8db6-842c6aba33b2%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
Am 10.11.2016 um 00:24 schrieb Marek Marczykowski-Górecki: > On Tue, Nov 08, 2016 at 10:37:02PM +0100, Achim Patzner wrote: > > Maybe I should have added the (obviously in my eyes obvious) argument: > > The current update-procedures are launched by a GUI-application and then > > open a window that is asking questions which need keyboard interaction. > > And in some cases the default answer (at least in Fedora) (which is > > making things worse – at least the default Xterm is looking different > > for Fedora and Debian) is not what you want. Or at least not what I want > > (aborting the update). Now someone wants to add another bloody > > interactive option that will require at least me to select the > > non-default option. > > I'd like to change this default - indeed it is very confusing, but I > don't know how. Only be recompiling it. This is hardcoded. I remember a "Linux-Stammtisch" in the area where the discussion over this topic nearly led to bloodshed so please avoid supplying patches unless you've got a black belt in something. > The only related option is to accept automatically. > Maybe this is the way to go? I'm currently living with about 10 Fedora-based templates. I'm usually updating the fattest, reviewing the list carefully and then go on with the update. The others are just getting a treatment using qvm-run (because I am annoyed by all those questions using the Manager). So using "-y" on the command line would not be exactly what I consider safe nor secure. > Personally I like to review list of packages to be updated, but I guess > most users don't do that. … until they have been burnt. I just spent hours finding out how I destroyed my native Arch system until I remembered that I'm EFI booting without grub and forgot copying the new kernel (which I didn't notice being installed because I didn't check the f* list) to /boot/efi/EFI/arch. > I think it's important to give the user some feedback. Fully automated > updates are somehow broken in most tools[1] - this is why we have this > terminal window, I guess I mentioned already that I'm mildly hating someone for using an xterm in default settings 8-). Although it is looking coool when you're updating 20 machines at the same time and showing your stamp collection to someone I've yet to figure out how to use a different font size for it. > instead of just some progress bar or something even less intrusive. Sometimes I like the way Ubuntu and the likes are handling things – until they break something. 8-) > But automatically shutting down the template (after user have a chance > to see update feedback) is a good idea. Something like "Press enter to > shutdown template, or Ctrl-C to just close this window". I once got into a serious discussion with Jordan Hubbard about the fact that I really disliked the sudden pop-ups asking for something innocent like "do you really want to shut down/have your cat slaughtered by satanists/vote for Trump?" with the least convenient option being the default while I was busily typing at something (you know that Macs are used by pushing mice and touching pads; that's why you can remove keys, one after the other, without any user noticing it). It's the same with the update process; the keyboard is not flushed before the "shutdown or not" question so any extraneous return key will still be in the buffer. Shutting a machine down isn't as bad as messing up your boot disk (which I did on the Mac by accepting a system update I would not have accepted if I had time to read the pop-up) but you should always be careful with users… Their attitude might type first, think later. Achim -- 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/ee71786a-1bf7-475b-3637-fee3a1e6bc38%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Nov 08, 2016 at 01:07:38AM -0800, Andrew David Wong wrote: > On 2016-11-07 10:05, Eva Star wrote: > > After template updated ask user at the console to shutdown current template. > > > > "Shutdown current template [Y/n]" > > > > Currently tracking a very similar suggestion here: > > https://github.com/QubesOS/qubes-issues/issues/832 Indeed this is similar, but not the same because it does matter when you shutdown the template - until you do so, child VMs do not see the changes. Created new issue here: https://github.com/QubesOS/qubes-issues/issues/2431 - -- 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? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYJ4nRAAoJENuP0xzK19csKJYH/232f3ts6oGOcVDvnqubDaEI NFSENa+ovKD9v7ZQjVmd0bdWlj7vH8HfhzCgzJZzFR0qLZb5sBHKmE1o3iqEkiYf HYi3WBKNgu7YtGhmS8iGLnBilSuJYjAyiaAzvVRbEHc8WFuy04U42lPzKSo/GMj6 FQxLXU/1lVz8TmwKVRkmVq+VuOxkO4OS58STu2PW5pKn3B1nx+qREzhNURhybYSV d4zgGQmvztNk88PG2sppnQAeYprqgR+fINwLqjPu8Mg7DfW2kb6EIpcFMJbNGqb3 WvV1ZmNPeIMAtzv8rvlvPE80niEOBsU0UDiTJ6T0YMlMBt/LnhEJeSX3yj2fm8o= =5wOE -END PGP SIGNATURE- -- 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/20161112212951.GC15162%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
> I hope I'm not too offtopic but a gui option to shut down multiple vms at > once would be cool. `qvm-shutdown --all --wait` -- will shutdown all VMs (if it helps) p.s. Marek, this command work NOT well. Time to time it freeze Qubes Manager and never end especially at the situations when need to shutdown cascade of VMs like this sys-net > sys-firewal -> sys-firrewall2 -> whinux -> sys-firrewall3 -> AppVm -- 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/ba2c73c5-7a00-4da1-93f3-ca08bc9ba72e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
I hope I'm not too offtopic but a gui option to shut down multiple vms at once would be cool. -- 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/ea416e8b-ae11-4fa6-ba0f-3d6c0d19404b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, Nov 08, 2016 at 10:37:02PM +0100, Achim Patzner wrote: > Am 08.11.2016 um 12:31 schrieb Andrew David Wong: > > >>> After template updated ask user at the console to shutdown current > > template. > > >> > > >>> "Shutdown current template [Y/n]" > > >> > > >> Currently tracking a very similar suggestion here: > > >> > > >> https://github.com/QubesOS/qubes-issues/issues/832 > > > > > Wouldn't a command-line tool qvm-update-template [--all] > > > [--shutdown-after-upgrade] [, ]* be much more > > flexible? > > > > Yes, but I don't think the primarily goal of that ticket is flexibility. > > Rather, I think it's to implement a quality-of-life feature that will > > benefit users generally, including novice users who never touch the > > command-line. > > Maybe I should have added the (obviously in my eyes obvious) argument: > The current update-procedures are launched by a GUI-application and then > open a window that is asking questions which need keyboard interaction. > And in some cases the default answer (at least in Fedora) (which is > making things worse – at least the default Xterm is looking different > for Fedora and Debian) is not what you want. Or at least not what I want > (aborting the update). Now someone wants to add another bloody > interactive option that will require at least me to select the > non-default option. I'd like to change this default - indeed it is very confusing, but I don't know how. The only related option is to accept automatically. Maybe this is the way to go? Personally I like to review list of packages to be updated, but I guess most users don't do that. > No. Thank you very much, but no. If someone is making things even more > like a text adventure they could just as well do it right, make the > update process command line based and give up interactive decisions in > favor of command line parameters to finally deliver a launch-and-forget > solution. That could be easily scripted without opening that barrel of salt. I think it's important to give the user some feedback. Fully automated updates are somehow broken in most tools[1] - this is why we have this terminal window, instead of just some progress bar or something even less intrusive. But automatically shutting down the template (after user have a chance to see update feedback) is a good idea. Something like "Press enter to shutdown template, or Ctrl-C to just close this window". [1] https://phabricator.whonix.org/T373 - -- 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? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYI7A9AAoJENuP0xzK19cslx4H/3JFzlpcZZxatNmBjcB9Fuuf gOgWK5iG8ql1ekKKYvGldOatjw3+c9pYGtY/u3jZTF5lrdifMO5kh1cbsnJ9EYJ8 Z7bjJ07Xa/3Now3fxfznBhe5tKpi+q6SqNjiGXNuSkZyoZqMfH+z1Zlv4FYXlft1 FlD5HpID7zJt90EAJVgQ5S1JAnDA++jmJDvIR/04H/LBiyCzJRrWw/4tctotzbOL wQa1pEa79Fz2fuw5UlWvkcGRMXR9H+Yu+oAJ0+TO/ObwGrSfwlqcOqg/qSNjFIm6 PAfxPM2iGuL/B0oRVi8ST2Zb50LLa5K5k2jCk8WGdBv2RisXMrXh2sJkLspwxeM= =dI89 -END PGP SIGNATURE- -- 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/20161109232445.GW7073%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
Am 08.11.2016 um 12:31 schrieb Andrew David Wong: > >>> After template updated ask user at the console to shutdown current > template. > >> > >>> "Shutdown current template [Y/n]" > >> > >> Currently tracking a very similar suggestion here: > >> > >> https://github.com/QubesOS/qubes-issues/issues/832 > > > Wouldn't a command-line tool qvm-update-template [--all] > > [--shutdown-after-upgrade] [, ]* be much more > flexible? > > Yes, but I don't think the primarily goal of that ticket is flexibility. > Rather, I think it's to implement a quality-of-life feature that will > benefit users generally, including novice users who never touch the > command-line. Maybe I should have added the (obviously in my eyes obvious) argument: The current update-procedures are launched by a GUI-application and then open a window that is asking questions which need keyboard interaction. And in some cases the default answer (at least in Fedora) (which is making things worse – at least the default Xterm is looking different for Fedora and Debian) is not what you want. Or at least not what I want (aborting the update). Now someone wants to add another bloody interactive option that will require at least me to select the non-default option. No. Thank you very much, but no. If someone is making things even more like a text adventure they could just as well do it right, make the update process command line based and give up interactive decisions in favor of command line parameters to finally deliver a launch-and-forget solution. That could be easily scripted without opening that barrel of salt. Achim -- 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/24af09d7-f174-a1b7-e0d9-ac7e659f93a4%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-11-08 03:20, Achim Patzner wrote: > m 08.11.2016 um 10:07 schrieb Andrew David Wong: >> On 2016-11-07 10:05, Eva Star wrote: >>> After template updated ask user at the console to shutdown current >> template. >> >>> "Shutdown current template [Y/n]" >> >> >> Currently tracking a very similar suggestion here: >> >> https://github.com/QubesOS/qubes-issues/issues/832 > > Wouldn't a command-line tool qvm-update-template [--all] > [--shutdown-after-upgrade] [, ]* be much more flexible? > > > Achim > Yes, but I don't think the primarily goal of that ticket is flexibility. Rather, I think it's to implement a quality-of-life feature that will benefit users generally, including novice users who never touch the command-line. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYIbeOAAoJENtN07w5UDAwmccQAKpiMzbhePkkj46KaVOQ5WoY K1AtMMhzmRnU1Faq0RHafTEc31UaJSNczioGwDQvFDszVU0D1Df+BspnKBHkDpBW zhAvtMm/vTMN7DnYVEWEfiAnyIwY2kGjWTq4tP3e1aEA/NW9G+r9OnwMVcLXFuBd SFV9oX7tbVmn4Xd/zMzsZlhV9I+8pxC72GAlQPsbfJwT/qDNwDN2nuJzpIqnfXVV BKJPQ3squBXR9hGBx03yGj9gRCJyZzvcMSQlv58nSjP9oCOYHJ3qls97qx4JVSLi exurkz8jtpVOBskGZXHZ9QNRpm5Pc4p8prgPzwNE/xkJ8gNAXWTeuJYb8Z4iY5H+ p4zim60oved4OxpeuYySzdl/x+ThyIrxPL2SAeDyeKfW/CIeXWL+J6Dho2aQxHXZ lCjmF+YWqEqANM4b3pAd6SGOiZfHR3yOuPYuxGIiquIYLC0/V5Smc7eZeN2nXdV2 vRzuExSUNvigR3xJru+zFNh56mrZgS55bPOZaLjI2z5ZZDmtgXOdl7vtWcw6AHM+ +oXzv3ZUB9JhR5TOPekYG2JaaqqoNvlW5j+V+S+D/giM1Bn7M+BiHWQrSAsNX45L dPKDSuvYXYP+v38SEI5I/ADlJxnjpVrmSD+MEnp+eFmZcL7/PCOCE9jXCuwK/ef1 knavpTYoo1VSqKr2quSn =IKkm -END PGP SIGNATURE- -- 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/c3386bf9-f1c9-3ddf-6995-f724dc82eb8a%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
m 08.11.2016 um 10:07 schrieb Andrew David Wong: > On 2016-11-07 10:05, Eva Star wrote: > > After template updated ask user at the console to shutdown current > template. > > > "Shutdown current template [Y/n]" > > > Currently tracking a very similar suggestion here: > > https://github.com/QubesOS/qubes-issues/issues/832 Wouldn't a command-line tool qvm-update-template [--all] [--shutdown-after-upgrade] [, ]* be much more flexible? Achim -- 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/04a97647-4ff9-0636-239d-55ce636e3f46%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [feature request] Shutdown template after update
See also https://github.com/QubesOS/qubes-issues/issues/2388 If we have appropriate metadata for each VM, we could automatically shut-down VMs if they were not running prior to triggering the update. This may be a preferable user experience. -- 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/CABQWM_CfB4nvHct3xQE3JtkR1bXjxf01D9cLYcpn8MF%2BxxMrew%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] [feature request] Shutdown template after update
After template updated ask user at the console to shutdown current template. "Shutdown current template [Y/n]" -- Regards -- 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/39d4981f-fc90-2588-9b00-30133c6e1d86%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] feature request: luksAddNuke
On Tuesday, February 17, 2015 at 3:17:08 PM UTC+4, Andrew wrote: > (and only ever work on clones of your disk). this will work only with clones of _not corrupted_ data. ofcourse user can have special method of destroying data, but having such extra method encapsulates key data nature (location of headers, ...) from user. if user somehow has low tech knowledge level, it should design and develop tools for traceless data destruction, if failed to find existing. R isnt fast and easy task. > Even if you encountered such a miraculously dumb government, you might > still be exposing yourself to criminal liability (or worse) for > knowingly causing the destruction. only in case of provable intentional destruction -- 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/b3c876c2-0568-4500-9e7f-f52c8feb99e8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
