Qubes Manager / Qubes 4.0 R3 ?
ThierryIT
Not possible anymore to hide "un-running VMs" ?
By the way, is it possible to create in Qubes Manager folders to be able to sort out VMs ?
Thx
![[799]'s profile photo](https://lh3.googleusercontent.com/a/default-user=s40-c)
[799]
ThierryIT wrote:
> Hi, Not possible anymore to hide "un-running
> VMs" ?
I haven't read anything and thought that it will come with Qubes 4rc4.
[799]
ThierryIT
ThierryIT
Yuraeitha
The Qubes Manager was only brought back because of people asking for it, but it was never intended or designed to work together with Qubes 4, and it did not receive the required re-make work to get a proper working manager, so the current old-new manager is buggy, slow, and newer Qubes 4+ features cannot be implemented as it is. The problem is Qubes 4 works very differently, and from what I read from earlier developer posts a year ago or so, it would take extensive work, effort and time to re-make the Qubes Manager for Qubes 4. In addition, the Qubes Manager was seen as being something akin to "bloat", it was not making Qubes feeling like you used any other normal computer system. The Qubes developers goal is not only maximum possible security, it's also user-ability and ease-of-use without making compromises to security. Removing the Qubes Manager was seen as a stepping stone towards that goal. While Qubes 4 isn't quite finished yet, and not ready to entirely let go of the Qubes Manager, the idea (I believe) was to get there as soon as possible. It was never intended to bring back the Qubes Manager, now known as the Qube Manager, notice the removal of the letter "s". The new-old Qube Manager's re-name, is probably to put emphasis on the fact that it's now only a VM-tool, and not a system-wide Qubes OS tool.
Also it's been explicitly said that no Qubes 4 existing features will be added to the new-old Qube Manager. Which might also hint towards no changes coming to Qube Manager. If anything, it has to be re-made almost entirely to work well with Qubes 4+, and currently no one is doing that. Maybe we'll see it in Qubes 5, or later? Who knows, but I don't think we need a manager like this though, Qubes 4 works just fine without one, just like how the developers intended it to be. Sure the Qubes 4 approach could be polished a bit to make up not having a Qube Manager, but they managed to get pretty far already, it just needs a bit more to make the Qube Manager completely redundant. Until then, either use secondary tools, or use the old-new Qube-Manager.
Try get used to the change instead. If you want to see memory/CPU use, then use other tools, like top, htop, xentop, etc. (the list is long).
The most difficult thing about Qubes, is to get used to change. The same difficulty getting used to Qubes for the first time using it, goes too for changing from Qubes 3.2. to Qubes 4.0. The very way a user is meant and designed to interact with Qubes, has indeed changed in Qubes 4.0.
Tom Zander
> Also it's been explicitly said that no Qubes 4 existing features will be
> added to the new-old Qube Manager. Which might also hint towards no
> changes coming to Qube Manager. If anything, it has to be re-made almost
> entirely to work well with Qubes 4+, and currently no one is doing that.
backends of Qubes it used (3.x).
I started a project using Qubes4-api and Qt5 APIs, though. See Ps at the
bottom of the mail.
[start rant]
The biggest issue i ran into is that Qubes4 is just too immature to actually
use for more than browsing and email. It was too painful for my desktop
full-time work machine.
I tried for 2 months, my significant other stated that I had been
extraordinary patient with Qubes when I finally stopped using it ;)
My problems are widespread;
* the admin-api is very immature and poorly implemented. Getting a stack-
trace in the server logs and no answer is just unacceptable. Unit tests,
anyone?
* system-tray is hopelessly broken. Losing apps because they don't show in
the system-tray up when you close them was fun!
* The design of qubes-daemon is too fragile, it starts/stops VMs and
patiently waits and hopes everything will work. I expected a much more
'hands-on' approach (at least for Linux kernels) with much more reporting. I
also lost data because apps aren't being quit, they are being killed on VM
shutdown.
* Why do I see 'lock'-icons for most of my windows in the task-bar?
* the documentation is very out-of-date.
* I don't know how, it may be fedora packaging, it may be qubes packaging or
configs, but the amount of KDE (apps running in dom0) crashes I had in the 2
months of using Qubes is greater than the amount i had in the previous 5
years. This boggles the mind...
* The graphics pipeline is hopelessly outdated. Its about a decade behind
the industry.
* Poor quality of many tools, the icon-copier copying the 22px icon from a
VM instead of the 256 one that was also there is just... sad.
* The amount of services, bash-scripts, config files, duplicated data in
qubes and then again in the system is horrible, under documented mess.
* rexecd validation being implemented using bash is a joke (mostly felt
because its extremely slow)
* total lack of mature end-user-focused tools. Swear to God. There are zero
today.
* Having nothing but python APIs for your operating system is something that
makes no sense. Python was never meant for servers, or even big
applications. Finding a full-stack python developer is more rare than
finding a Bitcoin C++ developer.
end-rant.
Qubes is an amazing idea, has some fantastic and genius concepts in it.
I hope many of those things will get fixed, although the list has grown so
long that I'm not sure it can without being forked.
ps. https://github.com/QubesController is the place where I wrote an already
pretty decent "Qubes Controller" using the new APis.
I'm open to adding anyone to the approved committers list that wants to work
on it.
--
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel
awokd
> The biggest issue i ran into is that Qubes4 is just too immature to
> actually use for more than browsing and email. It was too painful for my
> desktop full-time work machine. I tried for 2 months, my significant other
> stated that I had been extraordinary patient with Qubes when I finally
> stopped using it ;)
>
> My problems are widespread;
Working on it (where other contributors haven't already)! Am about halfway
through now.
> * The graphics pipeline is hopelessly
> outdated. Its about a decade behind the industry.
;) But no point rehashing the related GSoC threads. Your suggestion there
seemed valid.
I hope you continue to run the released version of 4.0 on a secondary
machine at least. I think you provide a valuable viewpoint.
Yuraeitha
I think discussion is good and healthy, though I don't feel it's entirely fair to paint it black and white like this. I can agree on many problems, but I think they look very different in different light and perspectives, so lets try shake it up a bit. I'm not claiming to be right, this is just my perspective of things.
The ancient city Rom wasn't build in one day, it took many decades and even centuries. And as awokd said, the security in Qubes is rapidly evolving in short time, which is hard to deny. Qubes is heavily disrupting the security industry, which has been too stagnant and slowly reactive developing over many years, rather than a proactive forward looking perspective, which Qubes has.
- The priority is first and foremost security, right? Everything else besides that is pretty much secondary or lower. Ease of use and emotional related things, such as good looking and appeal, will come even lower than secondary (don't get me wrong though, I do love good looking systems too my self).
While the Qubes OS team could need more funding and donations, I don't think they are feeling ready yet to go and market themselves before the security is on an even higher level. And this I think is very justified in a logical sense seen from an understanding of market perspective, once you start market it, if the security isn't good enough, then Qubes will just become a short-lived fire-fly that only lives 24 hours, before everyone forgets about it again. For proper marketing, you need to be ready before spreading the hype. This is why many open source projects dye out too, they don't live long enough to be ready to deliver, or they deliver too early or too late. As I see it, the Qubes developers are currently doing a good job enduring. Security is also the main target group to begin with too, so I feel it's overall very justified to focus all their energy on security and secondary ease-of-use problems, important mainstream hardware support, and so on.
We're in early times, and as I see it, currently the fundamentals are being build in Qubes. The structure which everything else ontop will be changed in the future. I think it's very wrong to look at Qubes 4 as how Qubes will look like in the future. This is a deep mistake from other Linux OS's which are very conservative, unchanging, and by all means have an ingrained reactive thinking pattern, rather than proactively thinking pattern. I think the Qubes developers have a good forward looking foresight, and this is part of the reason why I like it so much. But for this reason too, Qubes is often misunderstood if they do things in Qubes 4, which may first show its full potential in Qubes 5 or Qubes 6.
- There is also the question of how much of this is upstream issues? Not everything is Qubes to fix, and it certainly would be ill advized to start doing what for example Red Hat is doing and change the code, which has to be done everytime a new update arrives from upstream. Although I have to admit I have little understanding of codes.
- Also currently we're still seeing rapid development of security in Qubes, and it's still going. The primary developers of Qubes are busy, so I don't think it's justified to say any should shift focus to fix lower priority nice looks and appeals, like icons (although I do enjoy good looking systems, but it's too soon as there are other things to be done in Qubes first). Why are other developers from the outside not helping with this? The Qubes developers are busy enough with the security aspect as it is after all. Also if more people helped, and more put up donations (avoiding too early wide-spread hype though, there is a good timing for everything), then perhaps we can get issues fixed like missing icons, and so earlier than otherwise.
- Which programs and apps can't you run in Qubes? I mean, I can even run Android with Android apps, it's pretty amazing. What sort of programs do you have that can't run that well on Qubes? Maybe it can be fixed?
- Lets not forget, Qubes 4 was about future-proofing Qubes. Currently many things need to be fixed again after having ripped everything apart and putting it together with many new parts and design shape. Qubes 4 is in many ways, in my understanding, really about making the upcoming Qubes 5 and onward possible, which is to say, Qubes 4 may not seem so special, but I'm sure it will start to show and build up when we're seeing Qubes 5.
- I agree there are problems, and I'm happy to discuss it too. But we must not forget to put everything into different perspectives to see things in different ways. This too is why discussions like these are so good and amazing, it can bring out new perspectives to the mix for everyone taking part in it.
Unman
> * Having nothing but python APIs for your operating system is something that
> makes no sense. Python was never meant for servers, or even big
> applications. Finding a full-stack python developer is more rare than
> finding a Bitcoin C++ developer.
This is a joke though, no?
You obviously dont mean uses like Google, DropBox, YouTube, Reddit etc.
Perhaps you dont know about Eve Online? Mercurial? Blender?
There are exceptional developers working in many companies -Google,
NASA, Astra Zeneca, to name a few, all using python. The fact that
you arent comfortable with it is fine, but not a reason to reject it.
Tom Zander
> On Sun, Feb 04, 2018 at 08:14:57PM +0100, 'Tom Zander' via qubes-users
wrote:
> > * Having nothing but python APIs for your operating system is something
> > that makes no sense. Python was never meant for servers, or even big
> > applications. Finding a full-stack python developer is more rare than
> > finding a Bitcoin C++ developer.
>
> I'm not sure how much of this is just trolling.
> You obviously dont mean uses like Google, DropBox, YouTube, Reddit etc.
> Perhaps you dont know about Eve Online? Mercurial? Blender?
components as Qubes does.
Google is a good example, for instance they shipped proto-buffers. Which
have bindings in a long list of languages (20 or so).
Check wikipedia for those examples, reality is much more sobering that you
think.
> There are exceptional developers working in many companies -Google,
> NASA, Astra Zeneca, to name a few, all using python. The fact that
> you arent comfortable with it is fine, but not a reason to reject it.
developers.
Let me re-state the point for your benefit;
Having nothing but python bindings and having practically all your
components written in python is without a doubt very realistically limiting
the amount of people you can get hacking on Qubes. Add on top of that the
content matter, which is highly complex and in many cases includes
networking or cross-VM communication or hard-core linux components and you
limit the amount of people even more, to the extend I mentioned above.
Unman
> On Monday, 5 February 2018 00:55:34 CET Unman wrote:
> > On Sun, Feb 04, 2018 at 08:14:57PM +0100, 'Tom Zander' via qubes-users
> wrote:
> > > * Having nothing but python APIs for your operating system is something
> > > that makes no sense. Python was never meant for servers, or even big
> > > applications. Finding a full-stack python developer is more rare than
> > > finding a Bitcoin C++ developer.
> >
> > I'm not sure how much of this is just trolling.
>
> It is not trolling.
>
> > You obviously dont mean uses like Google, DropBox, YouTube, Reddit etc.
> > Perhaps you dont know about Eve Online? Mercurial? Blender?
>
> Absolutely none of these use python for anywhere near the same percentage of
> components as Qubes does.
The rest have been almost all Python at various points.
> Google is a good example, for instance they shipped proto-buffers. Which
> have bindings in a long list of languages (20 or so).
>
> Check wikipedia for those examples, reality is much more sobering that you
> think.
>
> > There are exceptional developers working in many companies -Google,
> > NASA, Astra Zeneca, to name a few, all using python. The fact that
> > you arent comfortable with it is fine, but not a reason to reject it.
>
> Thats moving the goalpost. Naturally there are many experienced python
> developers.
>
> Let me re-state the point for your benefit;
>
> Having nothing but python bindings and having practically all your
> components written in python is without a doubt very realistically limiting
> the amount of people you can get hacking on Qubes. Add on top of that the
> content matter, which is highly complex and in many cases includes
> networking or cross-VM communication or hard-core linux components and you
> limit the amount of people even more, to the extend I mentioned above.
>
irrelevant. It's a choice for Joanna and Marek to make. You are, of
course, free to rewrite Qubes and its components in a language you're
comfortable with.
Tim W
To me the only ones I feel have a right to comment on this specific topics are people that have at least contributed to the project. I am not saying I am correct but after 25 yrs of open source I have found there way to large a percentage of people wanting to be spoon fed and want and want and want. Entitlement mentality without offering anything constructive to the group collective projects.
IMO that is the largest issue Qubes struggles with as an opensource project. As do many projects. It seems plenty of people want this or that even demand it but rarely are any of them willing or even capable of contributing. Of course all projects needed basic users but this project really really needs more devs.
People complain about doc being outdated......then fix them. If a person is capable of loading Qubes OS they sure as hell are capable of creating or updating some Markdown pages even if it more cumbersome than a typical document format. A 3rd grader could do it.
With all the users commenting in the qubes-user list there is zero reason Docs should ever be outdated for more than a week or two in any area. I have redone and created a number of doc pages and a VERY minor amount of updating a couple script and conf files. (not much of a coder) But there is no reason there are not 20-30 people that over time should be keeping these docs up to date.
Tom has built a Qubes Controller (manager) based on the 4.0 code and went so far as to add in library package so other coding can be used to build. He has been super open to adding functions based on comments. If another person or two could help him with coding now that its not needed to just be python it could become the defacto Qubes GUI to manage the qubes system. That would take it off the plate of the core system devs. i plan to use his controller and if the QM does not work well I will stay with his controller.
You have to consider the finances of the core qube dev that are paid. This was a huge project moving Qubes forward. Consider Qubes 1 and how rough it was. Look at where we are at now. Its a long ways. 3.2 was 3 full major revisions and many sub revisions of the same basic code where 4.0 is very different compared to the other progressive steps of this Os before. 3.1 and finally 3.2 was getting very polished and it can be a bit of a shock when you have to take a step back in polish with such a over all change. Its going to take time but the bugs will be fixed and things will be polished.
I am not a coder so I will make not comments about python use etc other than it seems the reasons were memory-safety vs other. I tend to wonder if KDE issue seen are because they moved officially to XFCE. I think this may have been because of prefer of dev as users and also the low resources of devs to code. But as I said I do not have the knowledge to really speak on the topic beyond what I have seen.
mikih...@gmail.com
> > use for more than browsing and email. It was too painful for my desktop
> > full-time work machine.
> > I tried for 2 months, my significant other stated that I had been
> > extraordinary patient with Qubes when I finally stopped using it ;)
> - The priority is first and foremost security, right?
> Qubes is often misunderstood if they do things in Qubes 4, which may first show its full potential in Qubes 5 or Qubes 6.
I understand security is the priority, but I too think the current state of qubes is a mess. You make a good point about the future and Q5-Q6, and maybe you are both right. Besides surfing and emails, as an end-user I may have to wait for a few years to have a mature QubesOS.
I too cannot evaluate the code, but qubes-manager, system-tray, widgets paired with so many bugs is not a even close to any early beta version I would use as a daily OS. I will wait, for a few years, but that's really a highly optimistic and rather long-term speculation while dreaming about Qubes-IOT and Qubes-Cloud. All while implementing a new admin-api which roadblocked an already delayed update of QubesOS for new fedora versions and leaving qubes with half baked widget solutions in a bug-riddled mess.
Regards
awokd
to be expected; if not the point of release candidates.
If you want stable, run R3.2. I'm still using that as my daily driver, but
from what I see of R4.0rc4 it's to the point where I'm comfortable
switching as soon as I can fit it into my work stream. Others already have
and are (happily) running it daily.
rob_66
Yuraeitha <yura...@gmail.com> wrote:
> I think discussion is good and healthy, though I don't feel it's entirely fair to paint it black
> and white like this. I can agree on many problems, but I think they look very different in
> different light and perspectives, so lets try shake it up a bit. I'm not claiming to be right,
> this is just my perspective of things.
>
> The ancient city Rom wasn't build in one day, it took many decades and even centuries. And as
> awokd said, the security in Qubes is rapidly evolving in short time, which is hard to deny. Qubes
> is heavily disrupting the security industry, which has been too stagnant and slowly reactive
> developing over many years, rather than a proactive forward looking perspective, which Qubes has.
>
> secondary or lower. Ease of use and emotional related things, such as good looking and appeal,
> will come even lower than secondary (don't get me wrong though, I do love good looking systems
> too my self).
>
> While the Qubes OS team could need more funding and donations, I don't think they are feeling
> ready yet to go and market themselves before the security is on an even higher level. And this I
> think is very justified in a logical sense seen from an understanding of market perspective, once
> you start market it, if the security isn't good enough, then Qubes will just become a short-lived
> fire-fly that only lives 24 hours, before everyone forgets about it again. For proper marketing,
> you need to be ready before spreading the hype. This is why many open source projects dye out
> too, they don't live long enough to be ready to deliver, or they deliver too early or too late.
> As I see it, the Qubes developers are currently doing a good job enduring. Security is also the
> main target group to begin with too, so I feel it's overall very justified to focus all their
> energy on security and secondary ease-of-use problems, important mainstream hardware support, and
> so on.
>
> We're in early times, and as I see it, currently the fundamentals are being build in Qubes. The
> structure which everything else ontop will be changed in the future. I think it's very wrong to
> look at Qubes 4 as how Qubes will look like in the future. This is a deep mistake from other
> Linux OS's which are very conservative, unchanging, and by all means have an ingrained reactive
> thinking pattern, rather than proactively thinking pattern. I think the Qubes developers have a
> good forward looking foresight, and this is part of the reason why I like it so much. But for
> this reason too, Qubes is often misunderstood if they do things in Qubes 4, which may first show
> its full potential in Qubes 5 or Qubes 6.
>
> fix, and it certainly would be ill advized to start doing what for example Red Hat is doing and
> change the code, which has to be done everytime a new update arrives from upstream. Although I
> have to admit I have little understanding of codes.
>
> The primary developers of Qubes are busy, so I don't think it's justified to say any should shift
> focus to fix lower priority nice looks and appeals, like icons (although I do enjoy good looking
> systems, but it's too soon as there are other things to be done in Qubes first). Why are other
> developers from the outside not helping with this? The Qubes developers are busy enough with the
> security aspect as it is after all. Also if more people helped, and more put up donations
> (avoiding too early wide-spread hype though, there is a good timing for everything), then perhaps
> we can get issues fixed like missing icons, and so earlier than otherwise.
>
> apps, it's pretty amazing. What sort of programs do you have that can't run that well on Qubes?
> Maybe it can be fixed?
>
> fixed again after having ripped everything apart and putting it together with many new parts and
> design shape. Qubes 4 is in many ways, in my understanding, really about making the upcoming
> Qubes 5 and onward possible, which is to say, Qubes 4 may not seem so special, but I'm sure it
> will start to show and build up when we're seeing Qubes 5.
>
> everything into different perspectives to see things in different ways. This too is why
> discussions like these are so good and amazing, it can bring out new perspectives to the mix for
> everyone taking part in it.
Best regards, R.
Tim W
That is what I was getting at. Not to mention if more people would help out so much would be so much smoother and things would seem much more professional and polished i.e. the documents. I know Awokd has started. I now have gotten to a point where I have much more free time. As I am far from a top coder I plan to start going thru the docs topic by topic and updating adding breaking apart. I like the idea of separate 3.2 and 4.0 lines as they are so radically different and really the only complaint for not separating is updating and upkeep. That really should fall on the users once the devs have given us the initial how to on new things.
I really think we should get behind Tom's Qubes Controller and make that into the defacto QM. The ground work is already done and it has a feel that goes more with 4.0.
tom, I really hope you do not get too frustrated and walk as you really bring some good ideas and talent. What you did with the controller gui so many users like it. I think its great and allows for more and more functionality to be added to it. the same can not be said for the QM. I think that is a certainty. I am sure the qubes dev team sure would love to not have to keep the neutered QM as they already tried to drop it so..... Now with the library added that should open the door to those users that stated they wanted to help but were not python proficient to jump in and help with the controller app.
I am currently going thru all the setup script qubes build template options to find what templates compile correctly and what ones have bugs. After that I am happy to write up a markdown page for how to compile and install the Qubes Controller and use it. That can then be submitted to be added to the Qubes 4.0 Docs.
Cheers,
Tim
Tom Zander
> You are, of
> course, free to rewrite Qubes and its components in a language you're
> comfortable with.
Don't be so dramatic, I m not suggesting any such thing.
Tom Zander
> I am currently going thru all the setup script qubes build template
> options to find what templates compile correctly and what ones have bugs.
> After that I am happy to write up a markdown page for how to compile and
> install the Qubes Controller and use it. That can then be submitted to
> be added to the Qubes 4.0 Docs.
You should be able to get a lot of detials from this;
https://github.com/QubesController/qubes-api-cpp-lib/blob/master/Install.md
Tom Zander
> Working on it (where other contributors haven't already)! Am about halfway
> through now.
Tom Zander
> Why are you complaining about bugs when running a ".0rc" version? They're
> to be expected; if not the point of release candidates.
https://en.wikipedia.org/wiki/Software_release_life_cycle#Release_candidate
Release candidates are, like the word describes, not made unless the
developers are thinking that its ready to release but needs more real-world
testing to make sure.
Tom Zander
> People complain about doc being outdated......then fix them.
docs. I never managed to get that working.
The firewall page can also be a bit more detailed as-is, it assumes people
already know the actual setup of the qubes firewall ruleset. I don't, thats
why I went to that page.
> Tom has built a Qubes Controller (manager) based on the 4.0 code and went
> so far as to add in library package so other coding can be used to build.
> He has been super open to adding functions based on comments. If
> another person or two could help him with coding now that its not needed
> to just be python it could become the defacto Qubes GUI to manage the
> qubes system. That would take it off the plate of the core system devs.
> i plan to use his controller and if the QM does not work well I will stay
> with his controller.
awokd
> On Monday, 5 February 2018 08:00:35 CET 'awokd' via qubes-users wrote:
>
> Release candidates are, like the word describes, not made unless the
> developers are thinking that its ready to release but needs more
> real-world testing to make sure.
stability, you should be running R3.2. That's what it's there for. If you
want to help out the project and don't mind a few rough edges, by all
means try out R4.0 and contribute bug reports and/or code fixes if
possible.
awokd
> On Monday, 5 February 2018 04:34:35 CET Tim W wrote:
>
>> People complain about doc being outdated......then fix them.
>>
>
> If someone can figure out how to port-forward in 4.0, please do update
> the docs. I never managed to get that working.
>
> The firewall page can also be a bit more detailed as-is, it assumes
> people already know the actual setup of the qubes firewall ruleset. I
> don't, thats why I went to that page.
figure it out but tips/pointers are always welcomed!
awokd
> On Mon, February 5, 2018 6:01 pm, 'Tom Zander' via qubes-users wrote:
>> If someone can figure out how to port-forward in 4.0, please do update
>> the docs. I never managed to get that working.
https://www.qubes-os.org/doc/firewall/#port-forwarding-to-a-qube-from-the-outside-world
on R4.0, I'm not getting past the first step of:
Verify you are cutting through the sys-net VM firewall by looking at its
counters (column 2)
iptables -t nat -L -v -n [counters increasing]
iptables -L -v -n [not]
I wonder if it's an nft vs. iptables thing? Interestingly, this procedure
works fine:
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
.
Tom Zander
> I'm not getting past the first step of:
>
> Verify you are cutting through the sys-net VM firewall by looking at its
> counters (column 2)
The problem isn't limited to sys-net either, using netcat to listen on any
port on any (fedora based) appvm I could not get anything to connect to
those ports.
So, for instance, starting netcat on sys-firewall I could not connect to it
from sys-net.
Similarly, listening on a random VM and connecting to it from sys-firewall
failed too.
And I tried a lot of ways to convince the iptables to accept it...
I mostly used archlinux templates for appvms, which do not have the qubes
networking packages and thus the iptables list is empty. [1]
Listening there and connecting from it worked fine.
Hope that helps.
----
1) Personally I would say that simpler is better, or least surprises is
better. The current design where any appvm gets those complex firewall rules
is a bug. Only VMs that expose their network (providing) should run it.
awokd
On Tue, February 6, 2018 11:12 am, 'Tom Zander' via qubes-users wrote:
> On Tuesday, 6 February 2018 11:32:07 CET 'awokd' via qubes-users wrote:
>
>> I'm not getting past the first step of:
>>
>>
>> Verify you are cutting through the sys-net VM firewall by looking at
>> its counters (column 2)
>
> Yes, that sounds familiar.
>
>
> The problem isn't limited to sys-net either, using netcat to listen on
> any port on any (fedora based) appvm I could not get anything to connect
> to those ports. So, for instance, starting netcat on sys-firewall I could
> not connect to it from sys-net. Similarly, listening on a random VM and
> connecting to it from sys-firewall failed too. And I tried a lot of ways to
> convince the iptables to accept it...
>
> I mostly used archlinux templates for appvms, which do not have the qubes
> networking packages and thus the iptables list is empty. [1] Listening
> there and connecting from it worked fine.
>
> Hope that helps.
https://www.qubes-os.org/doc/firewall/#enabling-networking-between-two-qubes
working first try. Doesn't explain sys-net though which is using it too.
Anyone out there intimate with nft/iptables? My PR went through so the
document is up for grabs again if you want it! (Or please give suggestions
here and I can document it too.)
Alex Dubois
> On Monday, 5 February 2018 00:55:34 CET Unman wrote:
> > On Sun, Feb 04, 2018 at 08:14:57PM +0100, 'Tom Zander' via qubes-users
> wrote:
> > > * Having nothing but python APIs for your operating system is something
> > > that makes no sense. Python was never meant for servers, or even big
> > > applications. Finding a full-stack python developer is more rare than
> > > finding a Bitcoin C++ developer.
> >
> > I'm not sure how much of this is just trolling.
>
> It is not trolling.
>
> > You obviously dont mean uses like Google, DropBox, YouTube, Reddit etc.
> > Perhaps you dont know about Eve Online? Mercurial? Blender?
>
> Absolutely none of these use python for anywhere near the same percentage of
> components as Qubes does.
Having developed a Yubikey component for Qubes, I prefer to use Python when possible for transparency. The C bit I've done are opaque to the user (unless he compiled his install of Qubes, and reviewed the code). Not saying it is the default choice but pointing that Python has this benefit.
> Google is a good example, for instance they shipped proto-buffers. Which
> have bindings in a long list of languages (20 or so).
True that API use should be easy at least with Python and C. But C should only be used for core protocols.
Alex Dubois
I did this doc long long ago. 4.0 has a new networking model. I've just upodated to v4, I'll review it... sorry...
awokd
> [Re-titling this sub-thread]
> Anyone out there intimate with nft/iptables? My PR went through so the
> document is up for grabs again if you want it! (Or please give suggestions
> here and I can document it too.)
grabbed it. Thank you, Alex!
Alex Dubois
OK, networking is working in R4rc4, I have it working fine with a dozen of VM + my intranet traffic at home routing through QubesOS.
I've started to update the doc here: https://github.com/adubois/qubes-doc/blob/master/security/firewall.md
I am about to do a pull request for this first update.
I do not address the main part because I believe there is a bug with /rw/config/qubes-firewall-user-script not triggering on network change that I want to report and get an understanding on how it will be addressed.
awokd
> I do not address the main part because I believe there is a bug with
> /rw/config/qubes-firewall-user-script not triggering on network change
> that I want to report and get an understanding on how it will be
> addressed.
Alex Dubois
Yes thanks found it and commented on my needs in this type of context. for example, I spin up a web server, I need the FirewallVM to get a hook to update it's firewall rules accordingly.
Franz
On Sunday, 4 February 2018 18:10:44 CET Yuraeitha wrote:
> Also it's been explicitly said that no Qubes 4 existing features will be
> added to the new-old Qube Manager. Which might also hint towards no
> changes coming to Qube Manager. If anything, it has to be re-made almost
> entirely to work well with Qubes 4+, and currently no one is doing that.
The Qubes Manager is written to Qt4, which is equally outdated as the
backends of Qubes it used (3.x).
I started a project using Qubes4-api and Qt5 APIs, though. See Ps at the
bottom of the mail.
[start rant]
The biggest issue i ran into is that Qubes4 is just too immature to actually
use for more than browsing and email. It was too painful for my desktop
full-time work machine.
I tried for 2 months, my significant other stated that I had been
extraordinary patient with Qubes when I finally stopped using it ;)
* Having nothing but python APIs for your operating system is something that
makes no sense. Python was never meant for servers, or even big
applications. Finding a full-stack python developer is more rare than
finding a Bitcoin C++ developer.
end-rant.
Qubes is an amazing idea, has some fantastic and genius concepts in it.
I hope many of those things will get fixed, although the list has grown so
long that I'm not sure it can without being forked.
But try also to understand if there are conditions for your Qubes Manager to be incorporated as an official tool.
You wrote you accepted my offer to cover some efforts of a rewritten Qubes Manager with $5000. Do not leave me with this money, rather help us promote the idea that end users should pay for what is directly done for them like GUI.