Packages marked “## recommended” don’t have to be installed, maybe some packages marked “## dependency” could become “## recommended” after review and some if/then/else magic. (For example it wouldn’t be difficult to omit the vrms package for custom builds and with a little more code also for redistributable builds.)
However, I am buried in tasks, so I welcome help here.
As for how to create a minimal desktop environment, Occq and Cerberus have spent some thought here in this thread, I think.
When finally task https://github.com/Whonix/Whonix/issues/40 is done, I hope understanding Whonix’s internals gets much simpler. Also creating custom builds or Live DVD’s etc. should become much simpler, since then you can decide which of Whonix’s additions you like to use.
I have a minimal Whonix workstation VM with fluxbox. If I start it, and execute “startx” at the prompt, I get fluxbox.
How do I configure it so fluxbox starts automatically? I know that “startx” must appear in the relevant startup file, but I’m having no joy figuring out which one that might be.
Don’t know much about that stuff. However, I would guess, that stuff goes into.
Had a glimpse into TorBOX 0.1.3 source code, where we used openbox.
# startx automatically launches openbox and tint2 (taskbar)
echo " tint2 &
exec openbox-session" | sudo -u user tee ~/.xinitrc
So it looks like.
Works as well.
Perhaps put into ~/.xinitrc the following.
However, writing into /home/ is always a bit weird, unprofessional, problematic and should be avoided if possible. I don’t know if there is a way to configure autostart of fluxbox in /etc/ however.
Anyhow. As said earlier, when you manage to figure out a set of config files for a minimal desktop, I can do the Debian packaging.
[quote=“Patrick, post:60, topic:84”]However, writing into /home/ is always a bit weird, unprofessional, problematic and should be avoided if possible. I don’t know if there is a way to configure autostart of fluxbox in /etc/ however.
Anyhow. As said earlier, when you manage to figure out a set of config files for a minimal desktop, I can do the Debian packaging.[/quote]
I ended up with a crude hack. I commented out the code in /etc/profile.d/30_desktop.sh that starts /usr/lib/whonix/ram_adjusted_desktop_starter, and added:
if [ -z "$DISPLAY" ] && [ "$(tty)" == "/dev/tty1" ]; then
startx
else
return 0
fi
With that change, fluxbox starts just after timesync. I don’t see whonixcheck, however. I suspect that my change invalidated success status for whonixsetup. It had completed successfully in this VM. Executing whonixcheck in terminal yields a WARNING to finish whonixsetup.
Renaming the modified 30_desktop.sh as /etc/profile.d/50_desktop.sh didn’t seem to help.
Although this is a crude hack, it’s good enough for my present goal: demonstrating the feasibility of a Whonix-like LiveDVD.
Would you prefer that I write more about this here, or on Wilders? Here makes the most sense to me, because I haven’t heard a peep from anyone about this on Wilders. But this is your home, and I am but a guest here
Ram Adjusted Desktop Starter (RADS) starts whonixsetup if whonixsetup was never run when no desktop will be started (as far as RADS understands). Otherwise /etc/xdg/autostart/whonixsetup.desktop is supposed to start whonixsetup (when there is a GUI). Fluxbox / openbox seem not to implement the xdg standard, so autostarting whonixsetup should be automated there. Once you found a hook for that, this is simple and requires no code changes.
When you run “sudo whonixsetup” once, go through it, then whonixcheck should work as well.
Your new commands could be put into /etc/profile.d/45_something.sh. Probably no need to mess with /etc/profile.d/30_desktop.sh.
Maybe a feature can be added to RADS to startx. Needs more thought. [When a config option has been changed it will work for sure, if it is possible to autodetect this, we’ll see.)
The question is, if the “startx” runs in foreground or if it exists shortly after starting it. “startx &” might allow the other /etc/profile.d scripts to run.
You’re welcome to post here as well as to post on wilders!
Well, recall that this is a LiveDVD, and the workstation VM has already run whonixsetup. Given that, I don’t get why it needs to be run again. It will just take time, and any changes will be lost.
But maybe that is the simplest way to get whonixcheck to run properly
I can call both whonixsetup and whonixcheck from ~/.fluxbox/startup. I may need to improvise if “sudo whonixsetup” won’t run without entering a password.
I also need to get ControlPort working in the pfSense Tor gateway. I think that tor is dropping rights (to user _tor) too soon, and pfSense won’t let _tor manage the control port and its directory. I’ll ask pfSense support about that. But for now, getting a new identity is broken
Yes
OK, calling it “45_fluxbox.sh” would avoid potential confusion. But I do recall that 30_desktop.sh breaks the fluxbox load, because it invokes xdg, and xdg doesn’t seem to understand fluxbox.
I did attempt to understand RADS, but gave up But again, this is a LiveDVD. It will never get to running any of this unless 2.2 GB from “ram1.cpio.gz” on the DVD has fit in half of physical RAM.
It does seem to let time sync complete successfully.
Thanks I’ll start a new thread here. Soon I’ll have LiveDVD_0.1.iso (2.6 GB) online somewhere.
A matter of taste, I think. whonixsetup implements what tor-launcher (TBB’s Tor GUI addon) implements in TBB and what Tails also has implemented. Before attempts to establish any connections, that user is educated about available options. If bridge users don’t want to connect to the public Tor network, for circumvention reasons or because they want to hide Tor, then this feature is a real blessing. I guess in Tails Live it is the same. Every time you boot, you need to go through that setup again. Setting it to Tor-auto-connect-to-public-Tor-network might work very well for you, but I don’t think it would be a good general solution as default.
Apart from this, whonixsetup asks if you want to enable Whonix’s repository and which one. This encourages to install updates. But the Live DVD and updates is another topic. Not sure if Tails implemented a solution in meanwhile?
No problem. If you want this. whonixcheck is very modular. Any test can be disabled. (Although not all combinations are tested, but this one should be easy.)
I can call both whonixsetup and whonixcheck from ~/.fluxbox/startup.
For starting whonixsetup, I suggest to mimic /etc/xdg/autostart/whonixsetup.desktop. I.e. start /usr/lib/whonix-shortcuts/whonix-autosetup from ~/.fluxbox/startup.
For starting whonixcheck, that won’t be necessary. Well, there are two parts. whonixcheck is not the one you’re looking for, because whonixcheckd will get autostarted by /etc/init.d/whonixcheckd no matter if/what desktop environment. What I suggest is starting the message notification system, so you get whonixcheck’s results. Mimic /etc/xdg/autostart/msgdispatcher.desktop. I.e. try starting /usr/lib/whonix/msgdispatcher_xdg_autostart from ~/.fluxbox/startup.
I may need to improvise if "sudo whonixsetup" won't run without entering a password.
Won't be hard. It already as a /etc/sudoers.d exception. "sudo /usr/bin/whonixsetup" should work for scripts. And if not, that can be fixed.
I also need to get ControlPort working in the pfSense Tor gateway. I think that tor is dropping rights (to user _tor) too soon, and pfSense won't let _tor manage the control port and its directory. I'll ask pfSense support about that. But for now, getting a new identity is broken :(
For ControlPort, I'd suggest Control Port Filter Proxy (https://www.whonix.org/wiki/Dev/CPFP) (not yet well packaged to be used elsewhere, in time, but better don't hold your breath for it).
But I do recall that 30_desktop.sh breaks the fluxbox load
In other words, if you run /usr/lib/whonix/ram_adjusted_desktop_starter before fluxbox load, it won’t load? I am wondering how it is able to do this. It is a pretty simple script. If there is no desktop manager installed (such as kdm) it doesn’t start one. That’s about it.
xdg doesn't seem to understand fluxbox.
I'd say fluxbox doesn't understand xdg.
I did attempt to understand RADS, but gave up :( But again, this is a LiveDVD. It will never get to running any of this unless 2.2 GB from "ram1.cpio.gz" on the DVD has fit in half of physical RAM.
In that case RADS won't be very useful. It could however maybe handle this use case and start fluxbox. Depends on wheter this should become a private or redistributable thing.
It does seem to let time sync complete successfully.
Desktop environments are most likely not able to disrupt sdwdate's operation (see "tail -f /var/log/sdwdate.log"). I guess you're just not seeing the success notification, because it's message notification system (msgdispatcher) hasn't been started (explained above). Once you start it, you should see the notifications. (Requires notifiy-send [[[or kdialog]]] and zenity to be installed.)
[quote=“Patrick, post:64, topic:84”][quote author=mirimir link=topic=65.msg1743#msg1743 date=1398535500]
Well, recall that this is a LiveDVD,
[/quote]
I see.
That one I don’t understand.[/quote]
When I run a workstation VM for the first time, it runs whonixsetup. After that, it just runs whonixcheck and timesync. As I understand it, bootcdwrite creates a bootable and installable snapshot of the system. Booting such a LiveDVD, the workstation VM (and everything else) runs exactly the same as the source system did the next time that it was booted. Maybe “exactly the same” is too strong, but it does seem that way. There may be no Internet connection, of course, but that’s not something that whonixsetup deals with, right?
[quote=“Patrick”][quote author=mirimir link=topic=65.msg1743#msg1743 date=1398535500]
Given that, I don’t get why it needs to be run again. It will just take time, and any changes will be lost.
[/quote]
A matter of taste, I think. whonixsetup implements what tor-launcher (TBB’s Tor GUI addon) implements in TBB and what Tails also has implemented. Before attempts to establish any connections, that user is educated about available options. If bridge users don’t want to connect to the public Tor network, for circumvention reasons or because they want to hide Tor, then this feature is a real blessing. I guess in Tails Live it is the same. Every time you boot, you need to go through that setup again. Setting it to Tor-auto-connect-to-public-Tor-network might work very well for you, but I don’t think it would be a good general solution as default.[/quote]
OK, those are good points. I’ll take a look at Tails, and see how it’s addressed.
My focus initially has been on getting it to work
Well, there’s no problem updating it. But nothing persists. I’ll look at Tails.
[quote=“Patrick”][quote author=mirimir link=topic=65.msg1743#msg1743 date=1398535500]
But maybe that is the simplest way to get whonixcheck to run properly
[/quote]
No problem. If you want this. whonixcheck is very modular. Any test can be disabled. (Although not all combinations are tested, but this one should be easy.)
For starting whonixsetup, I suggest to mimic /etc/xdg/autostart/whonixsetup.desktop. I.e. start /usr/lib/whonix-shortcuts/whonix-autosetup from ~/.fluxbox/startup.
For starting whonixcheck, that won’t be necessary. Well, there are two parts. whonixcheck is not the one you’re looking for, because whonixcheckd will get autostarted by /etc/init.d/whonixcheckd no matter if/what desktop environment. What I suggest is starting the message notification system, so you get whonixcheck’s results. Mimic /etc/xdg/autostart/msgdispatcher.desktop. I.e. try starting /usr/lib/whonix/msgdispatcher_xdg_autostart from ~/.fluxbox/startup.[/quote]
I’ve looked in /var/log/sdwdate.log and there are no results, because the “Tor running” prerequisite isn’t satisfied (because ControlPort is broken).
Getting ControlPort fixed is the first step, I think.
Won’t be hard. It already as a /etc/sudoers.d exception. “sudo /usr/bin/whonixsetup” should work for scripts. And if not, that can be fixed.[/quote]
Yes, you’re right. But it’s picky about what will run without password (“sudo shutdown -hP now”) and what needs a password (“sudo ifconfig”). And I’m sure that it’s in the code somewhere.
For ControlPort, I’d suggest Control Port Filter Proxy (onion-grater, a Tor Control Port Filter Proxy) (not yet well packaged to be used elsewhere, in time, but better don’t hold your breath for it).[/quote]
As I recall, the error seemed very pfSense-specific. I’ll check.
[quote=“Patrick”]But I do recall that 30_desktop.sh breaks the fluxbox load
In other words, if you run /usr/lib/whonix/ram_adjusted_desktop_starter before fluxbox load, it won’t load? I am wondering how it is able to do this. It is a pretty simple script. If there is no desktop manager installed (such as kdm) it doesn’t start one. That’s about it.[/quote]
Trial and error is my friend here
I’d say fluxbox doesn’t understand xdg.[/quote]
Yes, of course. In the fluxbox world, it’s God. And when it’s faced with conflict, it just falls over But it’s very small, and good enough (with enough hiding, anyway).
In that case RADS won’t be very useful. It could however maybe handle this use case and start fluxbox. Depends on wheter this should become a private or redistributable thing.[/quote]
I haven’t looked into what happens on systems with not enough RAM. But because it’s a LiveDVD, it’s a simple test: “Does the machine have at least 6 GB RAM?” It’s “yes”, or “no”, right?
I could force a RAM test, but that seems overkill
Desktop environments are most likely not able to disrupt sdwdate’s operation (see “tail -f /var/log/sdwdate.log”). I guess you’re just not seeing the success notification, because it’s message notification system (msgdispatcher) hasn’t been started (explained above). Once you start it, you should see the notifications. (Requires notifiy-send [[[or kdialog]]] and zenity to be installed.)[/quote]
Actually, timesync doesn’t complete, because ControlPort is broken
When I run a workstation VM for the first time, it runs whonixsetup. After that, it just runs whonixcheck and timesync. As I understand it, bootcdwrite creates a bootable and installable snapshot of the system. Booting such a LiveDVD, the workstation VM (and everything else) runs exactly the same as the source system did the next time that it was booted. Maybe "exactly the same" is too strong, but it does seem that way.
I see. Had a different approach in mind here. My approach is "script this somehow to create an iso using Whonix's build script that anyone can boot" and your approach is "transform an installed already personally configured system somehow into a Live system". Your approach is very helpful as a proof of concept, to get instructions written, get people excited about it. Later it can translated into a build script.
Well, there's no problem updating it. But nothing persists. I'll look at Tails.
Also kernel upgrades can not be applied, because kernel upgrades stills require reboot and after reboot the upgrade is lost. Perhaps Tails can persist such upgrades in future. Things will get better when linux distros implement a feature to replace the kernel during operation (some are working on it, I've read somewhere).
I've looked in /var/log/sdwdate.log and there are no results, because the "Tor running" prerequisite isn't satisfied (because ControlPort is broken).
Ah. I see. Of course. /etc/sdwdate.d/31_whonix_connection_checker_plugin gets into the way.
As a quick solution to get this running, you could create a file.
/etc/sdwdate.d/50_user
And add.
DISPATCH_PREREQUISITE=""
Then the connectivity check using Tor’s control port gets disabled. sdwdate may initially fail after boot (and timesync will inform you) because it may start too fast, try to fetch the time before Tor is ready. However, as soon Tor is ready, you should be able to manually timesync.
A crude hack, that could work better:
DISPATCH_PREREQUISITE="sleep 30"
A better solution not using Tor’s control port could be writing a connection checker plugin, that doesn’t use Tor’s control port. Also people not liking Control Port Filter Proxy (CPFP) for security reasons would like that. A better solution which you already said would be getting CPFP working.
Yes, you're right. But it's picky about what will run without password ("sudo shutdown -hP now") and what needs a password ("sudo ifconfig"). And I'm sure that it's in the code somewhere.
As a crude hack, you could create a file /etc/sudoers.d/user.
sudo visudo /etc/sudoers.d/user
And add.
user ALL=(ALL:ALL) NOPASSWD:ALL
That would allow user “user” to run anything without password. If you make a list of things that you need to run without password, I can see to write the proper /etc/sudoers.d/ exceptions.
I haven't looked into what happens on systems with not enough RAM. But because it's a LiveDVD, it's a simple test: "Does the machine have at least 6 GB RAM?" It's "yes", or "no", right?
One could also boot Whonix-Workstation with 128 MB without GUI. Maybe useful for servers.
[quote=“Patrick, post:66, topic:84”][quote]
When I run a workstation VM for the first time, it runs whonixsetup. After that, it just runs whonixcheck and timesync. As I understand it, bootcdwrite creates a bootable and installable snapshot of the system. Booting such a LiveDVD, the workstation VM (and everything else) runs exactly the same as the source system did the next time that it was booted. Maybe “exactly the same” is too strong, but it does seem that way.
[/quote]
I see. Had a different approach in mind here. My approach is “script this somehow to create an iso using Whonix’s build script that anyone can boot” and your approach is “transform an installed already personally configured system somehow into a Live system”. Your approach is very helpful as a proof of concept, to get instructions written, get people excited about it. Later it can translated into a build script.[/quote]
Well, I have ~0 experience with programming, so the “install, configure and bootcdwrite” approach is what’s doable for me. And, as I wrote somewhere recently, using bootcdwrite and bootcd2disk, one can install from a bootcd, make changes, and then create a new bootcd. If that works in practice, users could independently update, modify, etc if they like.
As a crude hack, you could create a file /etc/sudoers.d/user.
sudo visudo /etc/sudoers.d/user
And add.
user ALL=(ALL:ALL) NOPASSWD:ALL
That would allow user “user” to run anything without password. If you make a list of things that you need to run without password, I can see to write the proper /etc/sudoers.d/ exceptions.[/quote]
Yes, that’s similar to what I did in the host:
One could also boot Whonix-Workstation with 128 MB without GUI. Maybe useful for servers.[/quote]
I’d probably go with different DVDs for desktop vs server.
I’ve been distracted by other projects. If Whonix users are ~1/x of Tor browser users, only about 1/(x^2) would bother with this approach. Or at least, not unless it were as polished as Tails, and that’s beyond my skills. But at least it’s a feasibility demonstration.
i know patrick discurage to install other desktop environments just for security reasons ,
kde use 1 ghz cpu and 768 mb ram ? xfce use 300 mhz cpu and 400 mb ram ?
i test xfce on workstation and gateway , and on linux host , all that together , the entire system runs very very smooth ! my laptop have 2.3 ghz cpu with vt-x .
but because patrick discurage that for secirity reasons i use the default kde on guests,
anyway i leave xfce on host , so now runs still smooth , but if i use for example kde on host to , will run slower the whonix because : whonix gateway-kde= 1ghz+768mb ram +
whonix worksation-kde = 1 ghz+768mb ram + linux host kde= 1 ghz+ 768mb ram = total cpu 3 ghz , i have 2.3 ghz ! and if i use xfce on linux host will give in my system 700 mhz cpu more !
@anonymityISright I think this is the wrong thread. This thread is about development, getting an alternative desktop environment running inside Whonix VMs for whatever reason. Not necessarily related to system resources. For the system resources discussion, the whonix system requirements recommendation? thread is enough.
No, I haven’t done more on LiveDVDs with VBox and Whonix. I couldn’t figure out how to pare down the systems enough. Maybe one of the newer light virtualization systems would be secure enough. Or maybe a Qubes LiveDVD with pared down VMs. But I doubt that I’ll get back to it anytime soon.
Anyway, this is a very cool new forum! Congratulations
creating a live system using Qubes sadly doesn’t change the fact that to boot it, an ungodly amount of RAM would be needed… Like you’ve said, there are only few things which could be “stripped down” from Whonix, as the current version seem to really only have the necessity’s. A lightweight virtualization solution sadly isn’t capable of changing that fact, what would be, would be the possibility of “streaming” a live system directly from the source, only loading in the necessary parts. Currently, speed wise this isn’t possible, though with the coming of USB 3.1, which promises read speeds of up to 10GB/sec, this may be possible. Only loading parts of the system in RAM would make it unnecessary to strip down any part of the system.
Qubes-Whonix also requires less RAM, because fewer services have to be started. It’s a bit like “terminal-only”, just with gui applications installed by default.
(* They are going for Live USB at the moment, dunno they will also be going for Live DVD at some point.)
