Hi,
I have seen Richard’s great c0vid fueled presentation (hope he gets better fast) on the conference and I was going to try MicroOS inside virtualbox with the provided .vdi image.
Most likely it is because I am totally on the wrong and did not understand a thing about MicroOS but I get to boot the image, it goes to the point were the display show keyboard and timezone configuration then a password for root and … that’s it … it boots to a cli and there is literally nothing i can do.
No GUI show up, distrobox is not installed for example.
Is it only my clueless ignorance about MicroOS or am I doing something wrong, or is it a problem with the .vdi image?
Regards.
What exact image did you use (show URL)? If you are really talking about MicroOS, your experience is correct - there is no GUI in default installation. It is not intended for running user facing components.
Exactly I’m am talking about microOS, not Aeon or any other “flavor”
I did not knew that was the case.
So MicroOS is more I can I say Server-oriented right ?
This one :
https://download.opensuse.org/tumbleweed/appliances/openSUSE-MicroOS.x86_64-VirtualBox.vdi.xz
I have searched OpenSuse portal and the net and could not find startup/howto documentation on MicroOS.
I would truly like to experiment with MicroOS to make it a server capable of running on virtual machine hosts … the less expensive hosting on the web … would be great if there were more tutorial or even available references to the existing ones.
So far, I skipped over all the marketing bulzz about MicroOS Desktop, Aeon, Kalpa etc. I got impression that there would be separate image(s) targeting these distributions. Now looking at (rather brief) wiki pages, it appears that they are not separate images but rather additional use cases for MicroOS. So, you are supposed to install any GUI you need yourself on top of MicroOS base image. Wiki recommends ISO which makes sense seeing that base VB image lacks container run time. Which you will need to install yourself.
Not sure who Richard is, or the presentation, or the referenced .vdi.
However, I installed MicroOS in a V-Box VM recently, with no issues. TW is the Host.
I simply downloaded the most current .iso image (MicroOS w/Plasma) and added it as the bootable for the new VM.
The installer showed up as expected … of course, it’s not a GUI (never has been my experience) … but the install took about 10-15 minutes and is running great.
AAMOF, I’m typing this reply while inside the MicroOS VM
For Aeon images are built in openSUSE:ALP:Products:Aeon project and can be downloaded from /repositories/openSUSE:/ALP:/Products:/Aeon/images - openSUSE Download. Looking at Aeon pattern, these images should include basic GNOME desktop. I have not tried them.
@keyb_user1 You might want to have a look at this from Richard if you just want a bare MicroOS install… https://rootco.de/2020-12-09-microos-pi-network-monitor/ and add some combustion foo (hint mount the USB device to your vm before boot) to add additional things…
Not server oriented as such, just the bare minimum to start from and expand how your wanting the system to function.
1 Like
@keyb_user1 Have a read here, whilst libvirt/kvm I suggest you look at this rather than the third party tools… https://github.com/89luca89/distrobox/blob/main/docs/posts/run_libvirt_in_distrobox.md
1 Like
This is why we changed the names.
MicroOS is not intended for the desktop, but as a server, and does not include any graphical user interface. It’s primary use is as an immutable, predictable, and atomically updated workload host, be it for containerized or virtualized workloads.
Does this mean you can’t run a desktop on top of it? Of course not, but it’s going to require some work on your part to get it working, to the best of my knowledge, if you currently grab any image other than the .iso from MicroOS Downloads you are going to get a very minimal installer, that only contains the base system.
openSUSE Aeon, and Kalpa, are deliberately crafted GNOME and Plasma desktop variants, built on top of the MicroOS Base. The only currently supported way to install them, is with the .iso images, from the above referenced download link.
The images that you may find at ALP:Products:Aeon are not currently recommended for end user installation and are in no way, shape, or form, to be considered definitive or stable, as we are still sorting out our new build processes within the ALP framework, including the installer. We are in a period of flux right now, while sorting this out, after the name change.
So in summary, the only supported way of getting a “MicroOS Desktop” is to download the .iso from from the MicroOS Portal, and install it via the existing YaST based installer contained therein.
Thanks I will try that latter meanwhile I installed a couple of new VM’s (from virt-manager on my Leap machine) just to test the several preavailable “flavors” of MicroOS.
Quit frankly my idea was to use it as a stand-alone server for hosting on VM’s online.
I have to say it is not quite what I expected.
@keyb_user1 then you would want to go down the distrobox route, good thing is you can test this on your local machine, if it all goes pear shaped you can just delete the distrobox container and move on…
I suspect the main issue would be vm storage outside of distrobox, else when the container is deleted, so goes all the data…
It’s all doable, just a process…
So at least for the default distrobox (created by distrobox create), anything that you work on in your $HOME anyway, is going to remain, no matter how many times you delete and recreate the container.
I don’t know about other directories within the filesystem.
I’ve been testing from the iso the multiple MicroOS “flavors” and quite frankly I do not think my server use case fits the purpose of MicroOS, either that or I am not yet skilled enough to get the all thing working.
My idea and use case was to deploy a MicroOS Web app that is totally stand-alone running on a virtual-host facing the web. On one of those less expensive KVM offers.
One of the things to install would be something like ISPConfig.
That is the MicroOS server would require:
- iptables
- ssh access
- http server (apache2)
- Java
- tomcat
- MariaDB
- Redis
- PHP
and some other services running on MicroOS, more precisely on distrobox.
I still did not get how to use iptables … not even Susefirewall.
And also ISPConfig would be one of the applications running inside distrobox. I’m not even certain that can be done since most of the tasks performed by ISPConfig would be to write setup parameters on things like postfix, DNS server (bind), apache configurations and the like …
I find that troublesome if I can not use iptables or susefirewall, preferably iptables directly.
But I’m still going to give it a try.
There is no need for a firewall on MicroOS, as your networking setup is intended to be done with your containers, there’s no services running on the base system.
The only ports that will be facing out to the world are the ones that you enable in your containers.
Further to what @sfalken said. For ssh, that’s available on the base system from the getgo, combustion or ignition can set all that up.
Consider using vagrant to spin up a MicroOS install for testing…
1 Like
I truly wish that was the case … there is at a minimum the all important ssh. I did not yet worked on the issues and please do not take my advice as written in stone since this is all new and fresh to me (*). But in case you need for example multiple domains and subdomains for different guests on your host I believe the network layer must work on the Host system. The guests only operate the services themselves (httpd, database, sftp, your code with java/php/whatever).
Moreover, for any internet facing system you need not only to install ssh with adequate setup since that is going to be the main target of all sorts of attacks, but also things like for example fail2ban (preventive measures at a minimum to block recurring fake accesses ) … in order to prevent ssh ports being flooded with accesses from the same sources with multiple attempts to get in.
Networking configuration and protection is fundamental to any internet facing server.
If you have a cluster were any node Only deals with a certain task, then you are in another type of situation.
the issue is:
- ssh
- Bind
- iptables
and potentially highly related and integrated services like email (postfix for example)
All of those are highly integrated with the base networking software infrastructure on the Host, iptables for example is literally kernel-level filtering.
I am just pointing out potential troubles on this sort of scenario.
(*)Note: When I say this is all new and fresh I mean MicroOS, I still remember the first ever virtualization experiment: Linux User Mode … running Linux inside Linux … 
been using all types of virtualization all these years. Sadly for the last few years I have not got into hands down Virtualization since it is all simply click and run (major bugger!)
It’s not required to have that installed on the host. You use a container running something like caddy, or nginx-proxy or other “reverse-proxy” to handle your domains, if you’re running multiple containerized services on the same host.
Not that simple. Let’s make the situation clear:
I need a Single ISPConfig instance to control Multiple domains and sub-domains and their user email and webapps, bind (DNS) and many more things (disk quotas,access etc). Because otherwise Each container would have it’s Own ISPConfig install … defeating the Purpose of a centralize Single ISPConfig for all domains and subdomains, that is a Lot more work and complexity on each container install of ISPConfig .
This can Only be done If that same instance (irrespective of the scenario used single on host or multiple on containers) has control of:
- iptables
- DNS
- postfix
- Local Httpd server.
- Many more things like Disk quotas for each domain
ISPConfig is an Integrated solution to control All services on a web Server or a cluster of servers (those can be local container instances ). But it requires also control of the network layer (even things like disk quota ) … iptables (it includes a firewall) and Bind and all sorts of other OS Services.
The problem is that in Both cases either ISPConfig has total control of : postfix, Bind, httpd and iptables and much more.
Or:
ISPConfig is installed on the Host and has control of the exact same services (iptables, bind, postfix and the like) for the other container instances to use on that same host.
And in this later scenario we are again defeating the purpose of MicroOS … installing ISPConfig on Host together with httpd and way more stuff … (postfix etc). It would be a transactional-update pkg install nirvana on steroids …
And over that the host still would need a Minimum of ssh, iptables mainly to run fail2ban.