[qubes-users] Suggestions for Qubes troubleshooting community.

Mailing Lists qubes-users
1

Hello,

This google group is too hard to follow for many users because it is uncategorized. It is too hard to find the appropriate information in this particular format of discussion board. Google groups is an unsatisfactory way to attend to the needs of general Qubes OS users due to the primitive nature of this posting format. I propose that a different discussion board be created, which can be more easily followed.

A categorized layout would be much preferred. Furthermore, a dedicated administrator and/or a general set of posting rules would highly benefit all parties involved. It would be nice if this was connected or officially affiliated with the Qubes OS website or team.

The Qubes OS community might grow larger if trouble shooting information was more accessible to the general user, especially the beginner or uninformed user. I charge any member to attempt these things, redirect me to existing ones, otherwise I may take the initiative upon myself to create these things.

Food for thought. Cheers.

1 Like
2

I was actually thinking about setting up an "Unofficial Qubes Users/Community" wiki a while back, but I didn't end up doing anything because I wasn't sure if it was a good idea. (Didn't want to encroach on the official wiki or cause headaches for Joanna and Marek. Also wasn't sure if there was much demand for such a thing.)

But I think it could be useful. For example, the TorVM instructions (http://qubes-os.org/trac/wiki/UserDoc/TorVM) have been missing a step for months. (The missing step is that you have to set your firewallvm as your new torvm's NetVM.) This is really simple and kind of obvious if you're pretty familiar with Qubes, but it understandably tripped up some people who were newish to Qubes. IMHO, Joanna and Marek have much better things to do with the time they spend on Qubes than to fix stuff like this. Frankly, their time/skills would be wasted going through and correcting every little error and omission of this kind. But it's a perfect task for someone like me, who can't really contribute to the Qubes project in a more constructive way right now. So, one advantage to setting up an "unofficial wiki" is that we could have a page on setting up TorVMs, and say, "Note: This step is missing from the official instructions page, but you need it to get the thing to work." We could also have a page for "common problems," like the whole Network Manager debacle. Then we can just link to the relevant page if people ask about it.

Potential problems: What if people come along and start vandalizing the wiki or subtly implanting misinformation? Will maintenance be too much work? Will there be enough admins/editors to keep all the info accurate, up-to-date, and useful?

All in all, I would not want to do something like this without the blessing of Joanna and Marek. I respect their decision to keep the official wiki closed. I would probably do the same with a project like this. If we were to have a "users wiki" of some sort, I think its main function should be this: We write articles that aim to be useful to other users. If Joanna and Marek think they're useful or improve on an existing official wiki page, then they can choose to copy/paste, in whole or in part, to the official wiki (and edit content as they please). If not, they just ignore it. There would be a disclaimer on the front page warning all users of Qubes that they trust the information at their own risk, since it could've been written by anyone, and that the official Qubes website supersedes everything in the unofficial wiki.

3

example this article by ix4svs:
https://apapadop.wordpress.com/2013/09/14/advanced-networking-with-qubesos-vpn-proxyvm/is
very good, plenty of useful details, but is only linked in an email of
this group. If one looses the email, or is new to Qubes, it is difficult to
think that such gem may exist or, even supposing that it exists, it is
difficult to identify the correct search keywords to find it in the mail
list.

The best available documentation of the web seems that of arch-linux. So I
would simply copy the organization of the best:

best
Franz

4

We all can contribute to the official wiki.

As I remember Joanna clarified the contribution rules:
http://qubes-os.org/trac/wiki/ContributingHowto

And we have a bug reporting guide also:
http://qubes-os.org/trac/wiki/BugReportingGuide

So If some has the knowledge and time to create useful content (like
documentation): let's do it. And send it to this list.
Some of us (me, for example) already has access to the wiki, so we
can extend is as we wish.

Suggestions, patches, written documentation are always welcome.

5

I was actually thinking about setting up an "Unofficial Qubes
Users/Community" wiki a while back, but I didn't end up doing anything
because I wasn't sure if it was a good idea. (Didn't want to encroach on the
official wiki or cause headaches for Joanna and Marek. Also wasn't sure if
there was much demand for such a thing.)

We all can contribute to the official wiki.

With all due respect, this is false. Editing the wiki is not open to everyone.

As I remember Joanna clarified the contribution rules:
http://qubes-os.org/trac/wiki/ContributingHowto

Actually, this page doesn't say anything about contributing to the wiki.

And we have a bug reporting guide also:
http://qubes-os.org/trac/wiki/BugReportingGuide

So If some has the knowledge and time to create useful content (like
documentation): let's do it. And send it to this list.
Some of us (me, for example) already has access to the wiki, so we
can extend is as we wish.

Suggestions, patches, written documentation are always welcome.

But then how do you explain the example I gave above with the TorVM documentation? (I am not trying to pick on anyone with this example; it is just an example.)

On July 17, Alex sent a correction to the TorVM documentation[1] to the qubes-users list, and it was ignored.[2] Even now, the documentation is still inaccurate. If someone wanted to find the missing steps, they would have to search through ~3 years worth of emails. (But first they would have to know what they don't know -- that they're missing something that they need to search for!)

[1]http://qubes-os.org/trac/wiki/UserDoc/TorVM
[2]https://groups.google.com/d/msg/qubes-users/fyBVmxIpbSs/g2koHeSWDg4J

6

I was actually thinking about setting up an "Unofficial Qubes
Users/Community" wiki a while back, but I didn't end up doing anything
because I wasn't sure if it was a good idea. (Didn't want to encroach on the
official wiki or cause headaches for Joanna and Marek. Also wasn't sure if
there was much demand for such a thing.)

I can't stop you from doing anything, but IMO "official unofficial wiki" will
make confusion, especially in case of conflicting information.

We all can contribute to the official wiki.

With all due respect, this is false. Editing the wiki is not open to everyone.

Yes. This is some tradeoff between having a lot of contributors to the wiki
(including low quality ones and spammers...) and having few but high-level
contributors. We don't have time to review each wiki change and revert if
necessary so we tend more to the second option.

Apparently this model doesn't works well... Posting a code patch on the
mailing list is simple, even git comes with handy tools for it (git
format-patch, git send-email etc). But posting some wiki update isn't (you
need manually describe which page, which line etc; also applying such change
require some work).
Currently we are discussing internally some change to policy to who we give
write access to the wiki. I hope this will improve the situation very soon.

As I remember Joanna clarified the contribution rules:
http://qubes-os.org/trac/wiki/ContributingHowto

Actually, this page doesn't say anything about contributing to the wiki.

This need to be fixed...

And we have a bug reporting guide also:
http://qubes-os.org/trac/wiki/BugReportingGuide

So If some has the knowledge and time to create useful content (like
documentation): let's do it. And send it to this list.
Some of us (me, for example) already has access to the wiki, so we
can extend is as we wish.

Suggestions, patches, written documentation are always welcome.

But then how do you explain the example I gave above with the TorVM
documentation? (I am not trying to pick on anyone with this example; it is
just an example.)

On July 17, Alex sent a correction to the TorVM documentation[1] to the
qubes-users list, and it was ignored.[2] Even now, the documentation is still
inaccurate. If someone wanted to find the missing steps, they would have to
search through ~3 years worth of emails. (But first they would have to know
what they don't know -- that they're missing something that they need to
search for!)

[1]http://qubes-os.org/trac/wiki/UserDoc/TorVM
[2]https://groups.google.com/d/msg/qubes-users/fyBVmxIpbSs/g2koHeSWDg4J

TorVM page updated, after 2 months...

7

>>
>>> I was actually thinking about setting up an "Unofficial Qubes
>>> Users/Community" wiki a while back, but I didn't end up doing anything
>>> because I wasn't sure if it was a good idea. (Didn't want to encroach
on the
>>> official wiki or cause headaches for Joanna and Marek. Also wasn't
sure if
>>> there was much demand for such a thing.)

I can't stop you from doing anything, but IMO "official unofficial wiki"
will
make confusion, especially in case of conflicting information.

We all can contribute to the official wiki.

>
> With all due respect, this is false. Editing the wiki is not open to
everyone.

Yes. This is some tradeoff between having a lot of contributors to the wiki
(including low quality ones and spammers...) and having few but high-level
contributors. We don't have time to review each wiki change and revert if
necessary so we tend more to the second option.

Yes contributors are top level. But is the documentation high level?

Developers tend to document for developers not for end users. So they tend
to miss steps, hints, links etc that may be obvious for a developer, but
are not obvious for an end user. So stopping many people from using Qubes

Good documentation does not require a high level developer, but certain
requires a high level documenter. Look, it is not easy to write in a way
that everybody involved can really understand. Or is this a software for
developers only?

And the errors? Well, everybody can make errors. But everybody can also
note and correct errors. The onus of correcting errors is *not* on
developer's shoulders. Also the level of an open documentation reflects the
level of users and I proudly think that Qubes users are second to none.

Apparently this model doesn't works well... Posting a code patch on the
mailing list is simple, even git comes with handy tools for it (git
format-patch, git send-email etc). But posting some wiki update isn't (you
need manually describe which page, which line etc; also applying such
change
require some work).
Currently we are discussing internally some change to policy to who we give
write access to the wiki. I hope this will improve the situation very soon.

Yes, it is a matter of organization, Arch-linux wiki did not reach the

outstanding level it is by sending contributions to a mailing list, hoping
someone pick them up.

There is plenty of contributions, results, hints, facilitations on this
mailing list, but none picked them up. Why? Obviously because developers
have to devote their time to software development not to pick up
contributions and results from a mailing list, organizing, categorizing
them and *maintaining them*.

So why a model that worked so well for Arch-linux (up to be an example in
linux distributions) may give not so good results with Qubes? I see only
one major difference: Qubes is devoted to security. Someone may create a
wiki page to teach how to attach a bluetooth dongle to vaultVM to easily
transfer data to the cell phone and a reader may think this is part of the
famous Qubes security framework.

Arch-wiki has guidelines for contributing
ArchWiki:Contributing - ArchWiki . It is
possible to do something similar with some additional guidelines for
security. It would be very helpful to identify a sort of discipline
security code stressing what is strictly prohibited publishing (connecting
dom0 to internet, etc), what is dangerous, but possible in certain limited
cases (using bluetooth in Darien Jungle) in this case it should be marked
in red, and finally what is secure. Well this is just an idea to address
this Qubes specific problem. Others may have better ideas. What matters is
to solve this problem, because it is a problem.
Best
Franz

8

Franz, You are right at most of the things you mentioned... but Qubes
is really not for everyone.

Actually TOR VM and its documentation is a contribution also, not
part of the official Qubes.
And if it is not trivial for someone that the TOR VM should be
connected to a netvm to work... that person will fail to use TOR (and
qubes) anyway.

Of courese this is just an example (maybe bad) and I also see that
this kind of limited access has several disadvantages need to be
solved...

I'm not familiar with trac but should be some kind of draft/moderation
feature/plugin what can be handy in this situation...

9

Arch-linux that also is not for everyone. Actually it is much more
difficult to install Arch-linux than to install Qubes. But this is why it
was important to develop a comprehensive wiki for arch-linux.
Arch-linux-wiki also is not for everyone. A linux beginner will find it
hard to follow the tutorials, but the same the documentation is huge. It is
an unbelievable large and detailed amount of work.

No administrator or group of administrators would never be able to do it.
How it works? Opening it like wikipedia encourages users to submit content.
So you have a lot of contributors. It uses even the same engine mediawiki
This thread explains it as an example

Is it better than a closed one? Well, you loose control. Anybody can modify
your posts. Yes moderators may be able to check it, but no guarantee. The
control is finally delegated to the people that use it. You can write
rules, but you have to trust others for controlling the rules are not
broken. Will it work with Qubes devoted to security? I do not know, there
may be a risk, but looking at the results of arch-linux wiki I would think
twice before rejecting the chance.

It may be there is a third way: opening the wiki to the direct contribution
of everybody, to encourage submissions, but limiting actual publication
only after approved revision of someone or a group in charge of it. Looking
for this third way I was only able to find one example Docuwiki integrated
with a special approval plugin https://www.dokuwiki.org/plugin:publish. If
there is interest I am willing to dig more about it.

Best
Franz

Best
Franz

10

This will cause wiki to be vandalized every few days, because opening up
free access to everyone will open up huge attack surface on the wiki app
and kids will be exploiting it for fun and vandalism all the time. While
this is not a big security problem for Qubes integrity, and we also
maintain regular backups of the wiki on remote servers, it still would
cause lots of administration headaches, and would generally make the
wiki useless. And, no, I don't believe we can have Trac, or any similar
app, to be reasonably bulletproof (assuming login access is granted to
everyone).

joanna.

11

It may be there is a third way: opening the wiki to the direct contribution
of everybody, to encourage submissions, but limiting actual publication
only after approved revision of someone or a group in charge of it. Looking
for this third way I was only able to find one example Docuwiki integrated
with a special approval plugin https://www.dokuwiki.org/plugin:publish. If
there is interest I am willing to dig more about it.

I was about to suggest something like that, but see it’s already been done. drat! or… good! depending…

This will cause wiki to be vandalized every few days, because opening up
free access to everyone will open up huge attack surface on the wiki app

If the wiki + plugin are reasonably solid, then it’d not be much fun for the vandals. I rather doubt the qubes site is really the focus of many kiddie’s attention. Does that plugin also autoreject-and-notify submitters if what they were proposing to change has changed while theirs were awaiting approval (some other submission was accepted, so they need to take another look and resubmit)?

Maybe have a small group of moderators, and let them issue moderated-submit privs on a fairly casual basis? Again, not much fun for the hit and run kiddies because they have to talk to someone, but as the submissions are moderated anyway, it wouldn’t be necessary to be too uptight when someone requests submit privs?

12

I would prefer this way...

In this case we do not have to fully open the wiki, instead we can
give limited acces to much more users.
And will se if its work or not.

(but I really not see that too many contributors are just blocked by
the current rules)

In any way Qubes project really needs a documentation team to be able
to maintain the official documentation.

13

This seems serious problem, not only for Qubes wiki, but generally. Would
it make sense to have a Qubes architecture server side? A template VM not
connected to internet and an AppVM connected to internet. Approving a new
post would mean copying it from AppVM to template VM and restarting both
templateVM and ApplVM. So any vandal work would be lost. Would it work?
Possibly Qubes needs too many resources to be used as a server.
Best
Franz

14

Nope.

Qubes is addressing desktop specific security issues. On a server we
can simply use any kind of virtualisation... but those are not even
help at this situation.

This wiki opening question is about:

1. trusting the contributors,
2. hardening the wiki software, and the hosting environment.

3. and we need a team who can approve/moderate and maintain the whole
documentation.

15

Or a suggestion in this direction would be to create a separate sandbox/nonofficial/acceptance wiki for contributors, and modifying the approval plugin to simplify the publication/removal of selected pages to the official wiki ? This way only the acceptance wiki is polluted, and can allow the creation of a bigger community / exchange board for discussion that are too complex to be followed in the googlegroup. – 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+unsubscribe@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. Visit this group at . For more options, visit .

16

project: http://www.mediawiki.org/wiki/Project:Sandbox . May it be used?

Also mediawiki has an extension for approval:
http://www.mediawiki.org/wiki/Extension:FlaggedRevs .

What is difficult to explain, for me, is the importance of having a neutral
posting mechanism that can encourage users to submit posts. There are
various aspects involved:
1. Posting a small tutorial or a simple correction/addition on this mailing
list for publication on the wiki is like pretending that this work is so
important that a moderator should pick it up, understand where it should be
pasted, and paste it to the wiki. Most people are more humble than that. So
they commit to do that only in the rare case in which they have something
really very important, not for a simple correction/addition. But what
makes documentation great are just the details.
2. Being able to see your post while you edit it in its context is a small
satisfaction, but it adds pleasure to a work that does not give much
reward. Add to that the fact that a wiki provides editing tools that lack
in an email, for example for presenting code in a special format.
3. The simple presence of a web-page designed to receive a contribution
shows that this contribution is appreciated and requested. This is a strong
encouragement.
4. Do not forget that even if open-source, developers have their name
associated with the success of the project. This can also mean favourable
exposure and advertising and perhaps even money, as the story of Linus
Torwalds tells. People who write documentation get absolutely nothing
back, so obviously need stronger encouragement, in a form showing respect
for their work.
5. These are not just words. There is wikipedia, arch-linux wiki and others
that prove what works and what doesn't.
6. It is easy for me to write, while am unable to do it and other ones need
to do the work to get this working. Isn't it? I only have money to offer,
if it may help. $1500, if there is a way to do it Joanna can approve.
Best
Franz

17

This is also a good idea.

In this case we can have a forum as well instead (or addition) to this
mailing list.
I also agree that a forum can be more categorized and structured than
a mailing list.

for this we need
- a hosting space
- and some maintainer too. (I'm ready do this if needed)

But would be nice to see what Joanna and/or Marek prefer...

18

As I understand all the reasons for separate/more open wiki, we prefer to stay
with current situation with one official wiki. We've recently invited some
more people to join the wiki editors group and I hope this will improve
situation for now. Whatever you say, open access to the wiki (even separate)
will produce more work from our side, more time which we'd prefer to spend on
project development.

Of course I can't stop you from starting some unofficial forum/wiki/whatever,
but lets stay with only one official site.