#TinyCoreLinux

[hackernewsrobot]

TinyX: Small Featured X Server

https://github.com/tinycorelinux/tinyx

[q4os-tde-official]

anyone wanna suggest some software to try working on my netbook?

keep in mind it has to be avaliable as a tcz package, since as far as i can tell thats all TinyCoreLinux can install

[unscramblegk]

Announcing Cloud-Init for On-Prem appliances

Today we're announcing the official release of cloud-init deployed on our On-Prem virtual appliances.

The entire setup is fully Open Source under the permissive MIT license, and can be used/tweaked by anyone as they see fit.

Cloud-init on-premises

For those unfamiliar with cloud-init, it's a tool installed on the appliance which allows it to be configured with certain settings on boot. The settings are not pre-baked into the VM, but rather fetched from the VM's host (ex: EC2, VMware, Proxmox, MaaS, etc). They can be obtained in the form of a removable drive (ex: /dev/sr0), or from a "Metadata URL" such as http://169.254.169.254/.

Pre-configured settings are fine for defaults, but there has always been a need to provide additional settings such as NTP, network, DNS, storage, apitoken, before the VM is first booted. That's where cloud-init comes in. It allows a true zero-touch deployment of On-Prem appliances on various on-prem AND cloud providers.

Unfortunately with TinyCore Linux and an immutable OS, that "feature" has always been impossible to implement, until now.

The changes we've implemented for cloud-init to work on our appliances only add a few MB (~3.8MiB) to the size of the appliance, and require an ugrade from Python v2.7 to Python v3.

How it works

We add a system overlay into the TinyCore Linux rootfs, along with 3 new extensions (and their dependencies) which are loaded on boot:

ifupdown.tcz

cloud-init.tcz

cloud-init-deps.tcz

The /opt/bootsync.sh will run cloud-init and then try to setup networking through /opt/network.sh, which is simply calling cloud-init once more with different arguments. The reason for this is to provide backward compatibility for existing On-Prem TinyCore deployments.

Note: If there is no usage of the network.tcz, jidoteki-admin.tcz, or jidoteki-admin-api.tcz extensions, /opt/network.sh can be removed from /opt/bootsync.sh and replaced with:

/usr/local/bin/cloud-init modules --mode config

Each step in the cloud-init runs can be found in /etc/cloud/cloud.cfg.

The config modules are bootcmd which are the actual Shell scripts found in /etc/cloud/scripts.

Customizations can and should be added to custom.sh and custom-once.sh. If it's not immediately obvious, the once.sh and custom-once.sh scripts will only run once per boot. Unlike typical cloud-init installations, the once scripts will run again on reboot (because the OS is immutable).

Userdata, Metadata, Vendordata

The Shell scripts provided for this cloud-init deployment will read settings from various files on the system, including any userdata or vendordata provided to the system.

The order of precendence for reading configuration values are:

backed up files from /opt/.filetool.lst

userdata from /var/lib/cloud/instance/user-data.txt

vendordata from /var/lib/cloud/seed/nocloud-net/vendor-data

Note: Metadata is only currently used by cloud-init to configure SSH public-keys. All other metadata is ignored, but still accessible to applications running on the TinyCore Linux appliance.

Userdata

Tested with EC2, Proxmox, and NoCloud, the userdata will be discovered by cloud-init and read directly from /var/lib/cloud/instance/user-data.txt. From testing, it appears cloud-init handles Base64 decoding of userdata automatically provided by EC2.

Note: Userdata is not parsed by cloud-init, but rather read manually by various Shell scripts. This means it is not possible for userdata to overwrite values from /etc/cloud/cloud.cfg, and it is not possible to provide userdata which contains a shell script or other malicious features. Userdata should only contain key: value pairs.

Vendordata

The vendor-data is added to the /var/lib/cloud/seed/nocloud-net/ directory on the rootfs. It is also possible to add a network-config (v1 config) to that directory for pre-configuring the network.

Note: Similar to userdata, the vendor-data is not parsed by cloud-init and should only contain key: value pairs (except for network-config, which is parsed by cloud-init's net-convert tool).

More info

For more information, please see the README.md from our Open Soure repository.

Moving forward

We're hoping to add cloud-init to all our customer appliances in the coming month, so all their customers can benefit from the advantages cloud-init provides.

As usual, feel free to contact us and let us know your requirements. We'll be more than happy to help modernize existing apps by deploying them as part of a well-designed on-premises virtual appliance (OVA).

[networkingreengirl]

The Green Girl's TinyCore Linux launched successfully in her GNS3.

[hackernewsrobot]

Tinyx resurrected Xvesa from the depths of Git history

https://github.com/tinycorelinux/tinyx

[networkingreengirl]

The Green Girl has a TinyCore Linux VMware VM in her GNS3 now. Whee!

[unscramblegk]

Inside Jidometa: A look at our Open Source Software

[Read part 2 of Inside Jidometa]

In this post, we’ll highlight some of the open source tools we’ve created and deploy in every Jidoteki appliance, including Jidometa itself.

The OS

We'll start from the buttom up. Jidometa is built on top of TinyCore Linux - a small footprint in-memory operating system built on GNU/Linux. We use the unmodified OS with a few minor changes.

The sources for the OS toolchain

The sources for the OS busybox

The TinyCore OS initramfs and kernel

The TinyCore OS scripts modifications

The kernel

TinyCore Linux ships with a slightly modified Linux kernel. In our tests, we were able to deploy our appliances with a completely unmodified (vanilla) Linux kernel, so we provide the full unmodified kernel sources.

The kernel build scripts

The sources for the Linux kernel

The extensions

Extensions are similar to Debian .deb packages and RedHat .rpm packages. In Jidometa, they are squashfs .tcz files which contain pre-compiled and stripped binaries. They're typically much smaller because we don't include man pages, headers, and other files not needed in an immutable OS.

The sources for the extensions

We have yet to publish all the build scripts for our extensions, but they all use basic commands:

./configure;make;make install

Anyone can easily rebuild them with the original sources.

The admin scripts

We always include our own Open Source scripts to help manage the appliance. The scripts vary in importance and are either written in POSIX shell, or PicoLisp. We're slowly working on replacing all our POSIX shell scripts with PicoLisp shell scripts.

The Jidoteki Admin scripts, which manage the appliance from the console

The Jidoteki Admin API scripts, which manage the appliance from a REST API

The helper scripts, which provide additional functionality to the appliance scripts

We have quite a few more administration scripts, but we haven't open sourced them yet.

The libraries

The Admin scripts are built on top of a set of open source PicoLisp libraries which provide the foundation for stable, tested, and functional tools. The libraries include:

A unit testing library, to help write simple unit tests for every PicoLisp script and library, and ensure correct functionality (as well as reduce bugs/regressions)

A JSON library, to natively parse and generate JSON documents directly in PicoLisp

A SemVer library, to help manage, compare, and validate appliance and update package versions

An API library, to help build simple REST APIs as quickly and easily as possible

The licenses

It's almost impossible to gather every single license for every single software used in the appliance. We provided the software source packages intact, which include all the unmodified license files as well.

Additional licenses can be found directly in the appliance in:

/usr/share/doc/License/

The ISOs

Since downloading all individual source packages can be quite troublesome at times, we also provide direct links to download ISOs which bundle all the sources together.

Fauxpen source

We're not running a fauxpen source operation here. Admittedly not all our code is Open Source, but we do our best to comply with the GNU and OSD licenses by making it easy for everyone to access the sources files for the appliances and binaries we distribute.

We're constantly releasing new open source tools and libraries, so make sure you sign-up for our mailing list to stay up-to-date on our work, tools, and solutions.

If you're looking to provide your customers with an on-premises virtual appliance, without being locked-in by your vendor, then contact us and we'll be happy to discuss your requirements.