Monday, 9 October 2017

What is resinOS - Documentation

What is ResinOS

Introduction #

ResinOS is an operating system optimised for running Docker containers on embedded devices, with an emphasis on reliability over long periods of operation, as well as a productive developer workflow inspired by the lessons learned while building

The core insight behind resinOS is that Linux Containers offer, for the first time, a practical path to using virtualisation on embedded devices. VMs and hypervisors have lead to huge leaps in productivity and automation for cloud deployments, but their abstraction of hardware as well as their resource overhead and lack of hardware support means that they are out of the question for embedded scenarios. With OS-level virtualisation as implemented for Linux Containers, both those objections are lifted for Linux devices, of which there are many in the Internet of Things.

ResinOS is an operating system built for easy portability to multiple device types (via the Yocto framework) and optimised for Linux Containers, and Docker in particular. There are many decisions, large and small, we have made to enable that vision, which are present throughout our architecture.

The first version of resinOS was developed as part of the platform, and has run on thousands of embedded devices on, deployed in many different contexts for several years. resinOS v2 represents the combination of the learnings we extracted over those years, as well as our determination to make resinOS a first-class open source project, able to run as an independent operating system, for any context where embedded devices and containers intersect.

We look forward to working with the community to grow and mature resinOS into an operating system with even broader device support, a broader operating envelope, and as always, taking advantage of the most modern developments in security and reliability.

Variants of ResinOS #

ResinOS currently comes in 3 different variants all built from the same source but with slightly differing features enabled or disabled. Each version of resinOS produces the following variants:

Version Name Variant Type Description
2.0.0+rev2 production This is the production version of the managed OS. This is the OS you should use for any production fleet deployments
2.0.0+rev2-dev development This version the development version of the above and should be used when you are developing a new application and want to use the fast local mode workflow. This variant should never be used in production.
2.0.0+rev2-standalone standalone This version is an unmanaged version of resinOS, it doesn't have the supervisor and does not connect to the management console. Use this variant if you want a stable linux OS to run Docker on.

Dev vs. Prod images #

The Development images are recommended while getting started with resinOS and building a system. The dev images enable a number of useful features while developing, namely:

  • Passwordless SSH into resinOS on port 22222 as the root user. So one can do ssh root@<DEVICE_IP> -p22222 and poke around to see how the system runs.
  • Docker socket exposed on via port 2377, which allows resin local push to do remote Docker builds on the target device.
  • Getty console attached to tty1 and serial.
  • Capable of entering local mode for rapid development of application containers locally.

Note: Raspberry Pi devices don’t have Getty attached to serial.

The production images have all of the above functionality disabled by default. In both forms of the OS we write logs to an 8 MB journald RAM buffer in order to avoid wear on the flash storage used by most of the supported boards. However, persistent logging can be enabled by setting the "persistentLogging": true key in the config.json file in the boot partition of the device.

Both Prod and Dev variants will also allow the setting of a custom hostname via the config.json, just add "hostname": "my-new-hostname". Your device will then broadcast (via Avahi) on the network as my-new-hostname.local. If you don't set a custom hostname, the device will default to <short-UUID>.local.

On the production variant, nothing is written to tty1, on boot up you should only see the resin logo on the HDMI screen and this will persist until your application code takes over the framebuffer. If you would like to replace the resin logo with your own custom splash logo, then you will need to replace splash/resin-logo.png file that you will find in the first partition of our images (boot partition or resin-boot) with your own image. NOTE: As it currently stands plymouth expects the image to be named resin-logo.png.

Standalone ResinOS #

ResinOS also comes in a Standalone or "Unmanaged" variant. This variant is exactly the same as the -dev variant but does not have the supervisor agent and has the resin VPN service disabled, so it will never connect to the management system.

The standalone version of resinOS is meant as an excellent way to get started with Docker containers on embedded systems and you can read more about this over at

ResinOS Components #

The resinOS userspace tries to package only the bare essentials for running containers while still offering a lot of flexibility. The philosophy is that software and services always default to being in a container, unless they are generically useful to all containers or they absolutely can’t live in a container. The userspace consists of many open source components, but in this section we will just highlight some of the most important services. Supervisor #

The supervisor is a lightweight container which runs on your device, manages your applications and communicates with our servers - downloading new application containers and updates to existing containers as you push them, sending logs to your dashboard. It also provides a useful HTTP supervisor API interface, which allows you to query update status and perform certain actions on the device.

Systemd #

We use systemd as the init system for resinOS and it is responsible for launching and managing all the other services. We leverage many of the great features of systemd, such as adjusting OOM scores for critical services and running services in separate mount namespaces. Systemd also allows us to easily manage service dependencies.

Docker #

The Docker engine is a lightweight container runtime that allows us to build and run linux containers on resinOS. ResinOS has been optimized to run Docker containers and has been set up to use the journald log driver and DNSmasq for container DNS resolution. We use AUFS as the underlying storage driver since it is arguably the most production tested storage driver in the Docker ecosystem. It also allows us to more easily support devices with older kernel versions and additionally gives us the ability to run on devices with Unmanaged NAND flash.

NetworkManager and ModemManager #

ResinOS uses NetworkManager accompanied by ModemManager, to deliver a stable and reliable connection to the internet, be it via ethenet, wifi or cellular modem. Additionally to make headless configuration of the device’s network easy, we have added a system-connections folder in the boot partition which is copied into /etc/NetworkManager/system-connections. So any valid NetworkManager connection file can just be dropped into the boot partition before device commissioning.

DNSmasq #

DNSmasq is here to manage the nameservers that NetworkManager provides for resinOS. NetworkManager will discover the nameservers that can be used and a binary called resolvconf will write them to a tmpfs location, from where DNSmasq will take over and manage these nameservers to give the user the fastest most responsive DNS resolution.

Avahi #

In order to improve the development experience of resinOS, there is an Avahi daemon that starts advertising the device as resin.local or <hostname>.local on boot if the image is a development image.

OpenVPN #

ResinOS will provide the user with an OpenVPN server that they might use. It is worth noting that this server will be disabled by default and manual interaction from the user is needed to activate and configure this server to their needs.

Stateless and Read-Only rootFS #

ResinOS comes with a read-only root filesystem, so we can ensure our hostOS is stateless, but we still need some data to be persistent over system reboots. We achieve this with a very simple mechanism, i.e. bind mounts. ResinOS contains a partition named resin-conf that is meant to hold all this persistent data, inside we populate a Linux filesystem hierarchy standard with the rootfs paths that we require to be persistent. After this partition is populated we are ready to bind mount the respective rootfs paths to this read-write location, thus allowing different components (e.g. journald) to be able to write data to disk. A mechanism to purge this partition is provided, thus allowing users to rollback to an unconfigured resinOS image.

A diagram of our read-only rootfs can be seen below:

Image Partition Layout #

The first partition, resin-boot, host boot important bits according to each board (e.g. kernel image, bootloader image). It also holds a very important file that you will find mentioned elsewhere in this document (i.e. config.json). The config.json file is the central point of configuring resinOS and defining its behaviour, for example you can set your hostname, allow persistent logging, etc. resin-rootA is the partition that holds our read-only root filesystem; it holds almost everything that resinOS is. resin-rootB is an empty partition that is only used when the rootfs is to be updated. We follow the A-B update strategy for the resin HostOS upgrades. Essentially we have one active partition that is the OS’s current rootfs and one dormant one that is empty, we download the new rootfs to the dormant partition and try to switch them, if the switch is successful the dormant partition becomes the new rootfs, if not, we go back to the old active partition. resin-state is the partition that holds persistent data as explained in the Stateless and Read-only rootfs. resin-data is the partition that holds downloaded Docker images. Generally any container data will be found here. If you want to read a bit more about the partition layout, have a look at the resinOS github repo.

OS Yocto Composition #

The OS is composed of multiple Yocto layers. The Yocto Project build system uses these layers to compile resinOS for the various supported platforms. This document will not go into detailed explanation about how the Yocto Project works, but will require from the reader a basic understanding of its internals and release versioning/codename.

Codename Yocto Project Version Release Date Current Version Support Level Poky Version BitBake branch
Pyro 2.3 Apr 2017 Development
Morty 2.2 Oct 2016 2.2.1 Stable 16.0 1.32
Krogoth 2.1 Apr 2016 2.1.2 Stable 15.0 1.30
Jethro 2.0 Nov 2015 2.0.3 Community 14.0 1.28
Fido 1.8 Apr 2015 1.8.2 Community 13.0 1.26
Dizzy 1.7 Oct 2014 1.7.3 Community 12.0 1.24
Daisy 1.6 Apr 2014 1.6.3 Community 11.0 1.22
Dora 1.5 Oct 2013 1.5.4 Community 10.0 1.20

We will start looking into ResinOS’s composition from the core of the Yocto Project, i.e. poky. Poky has released a whole bunch of versions and supporting all of them is not in the scope of our OS, but we do try to support its latest versions. This might sound unexpected as we do not currently support poky’s last version (i.e. 2.1/Krogoth), but this is only because we did not need this version yet. We tend to support versions of poky based on what our supported boards require and also do a yearly update to the latest poky version for all the boards that can run that version. Currently we support three poky versions: 2.0/Jethro, 1.8/Fido and 1.6/Daisy.

On top of poky we add the collection of packages from meta-openembedded. Now that we are done with setting up the build system let’s add Board Support Packages (BSP), these layers are here to provide board-specific configuration and packages (e.g. bootloader, kernel), thus enabling building physical hardware (not emulators). These types of layers are the ones one should be looking for if one wants to add support for a board; if you already have this layer your job should be fairly straightforward, if you do not have it you might be looking into a very cumbersome job. At this point we have all the bits and pieces in place to build an OS. The core code of resinOS resides in meta-resin. This layer handles a lot of functionality but the main thing that one should remember now is that here one will find the recipe. This layer also needs a poky version-specific layer to combine with (e.g. meta-resin-jethro), these two layers will give you the necessary framework for the abstract resinOS generation. Now for the final piece of the puzzle, the board-specific meta-resin configuration layer. This layer goes hand in hand with a BSP layer, for example for the Raspberry Pi family (i.e. rpi0, rpi1, rpi2, rpi3) that is supported by the meta-raspberrypi BSP, we provide a meta-resin-raspberrypi layer that configures meta-resin to the raspberrypi's needs.

Below is a representative example from the Raspberry Pi family, which helps explain meta-resin-raspberrypi/conf/samples/bblayers.conf.sample.

Layer Name Repository Description
meta-resin This repository enables building resinOS for various devices
meta-resin-jethro This layer enables building resinOS for jethro supported BSPs
meta-resin-raspberrypi Enables building resinOS for chosen meta-raspberrypi machines.
meta-raspberrypi This is the general hardware specific BSP overlay for the Raspberry Pi device family.
meta-openembedded Collection of OpenEmbedded layers
meta-openembedded/meta-python The home of python modules for OpenEmbedded.
meta-openembedded/meta-networking Central point for networking-relatedpackages and configuration.
oe-meta-go OpenEmbedded layer for the Go programming language
poky/meta Core functionality and configuration of Yocto Project

Raspberry Pi + Docker: HypriotOS 1.0.0 Linux Brings Containers To Your Pi

Raspberry Pi + Docker: HypriotOS 1.0.0 Linux Brings Containers To Your Pi

hypriotos bring docker on raspberry pi

Short Bytes: HypriotOS 1.0.0 release recently arrived. It enables you to run Docker containers on entire Raspberry Pi family. HypriotOS is a Debian derivative that comes with out of the box Docker Engine 1.12.1. You need to simply install HypriotOS on your SD card using Hypriot flash tool and run a couple of commands to get this OS up and running.

If we take a look at some of the most impactful technology stories of the past few years, we can easily put Raspberry Pi, a tiny Linux-based single board computer, in the race. Earlier this year, we witnessed the launch of Raspberry Pi 3, a new version with built-in wireless and more powerful 64-bit processor.

This versatile computer already supported Linux-based operating systems and Windows 10 IoT Core. Recently we saw the release of HypriotOS v1.0.0 “Blackbeard”. It’s a new Debian derivative that’s developed to run Docker on your Pi.

Here’s what the official announcement on HypriotOS blog says:

“Today we proudly present our 1.0.0 release of HypriotOS – a container OS that takes you from Zero to Docker within 5 Minutes only, on any device of the complete Raspberry Pi family.”

It’s perhaps the first Linux distribution to offer Docker support for Raspberry Pi. Out of the box, HypriotOS v1.0.0 comes with Docker Engine 1.12.1 and the latest versions of Docker Machine and Docker Compose.

This lightweight operating system needs just 600MB of storage space to install and run. To get this OS up and running, you need to install HypriotOS flash tool and run the following command.


After this, put your SD card into the Pi and turn on the power. After connecting to a Raspberry Pi, the booting up process just takes five minutes.

Here’s the download link: HypriotOS 1.0.0

HypriotOS 1.0.0 feature highlights:

Here are the major features of HypriotOS 1.0.0. Take a look:

  • Lastest Docker Engine 1.12.1 with Swarm Mode
  • All Raspberry Pi versions are supported
  • Easy flashing with HypriotOS flash tool
  • Easy installation and configuration
  • High performance out of the box
  • Enhanced security
  • Download package is just 232MB

Apart from this Docker integration, Raspberry Pi is also expected to be supported by Google’s upcoming operating system, Fuschia. Another important news comes from Redmond, that has just released the Anniversary update for Windows 10 IoT Core.

For more changes and detailed information about HypriotOS, please read the release notes.

Did you find this article helpful? Don’t forget to drop your feedback in the comments section below.

Also Read: Raspberry Pi or Arduino — Which Board Is Best For A Beginner?

Sunday, 18 December 2016

Linux and the UK IPbill

Will openSUSE have a backdoor or will it be safe?

isn't Suse part of Micro Focus, which is British? Hence my concern.

openSUSE Chairman replies on :-

[–]rbrownsuseopenSUSE Chairman 30 points 6 days ago* :-

SUSE is part of Micro Focus, correct.
openSUSE is a community producing Linux distributions with all of its code and submissions very much in the open.

Our primary code servers are hosted in Germany, sponsored by SUSE Linux GmbH

If the IPbill does apply to the openSUSE Project (I believe it does not), I have no intention of following the provisions which give the UK government an opportunity to meddle in our communities code before release.

If any backdoor were added it would be done so in a transparent way that would be easily noticed in OBS. note: the project already firmly follows upstream projects first and very strictly documents divergence from those upstreams. It's very easy to see every patch we carry in every package.

Even if I had a different opinion, I still think it would be unworkable- the Tumbleweed release process alone would probably overwhelm Her Majesties Government with more requests per week than most companies would produce in many years.. "

Linux chief: ‘Open source is safer, and Linux is more secure than any other OS’ (exclusive)

J. O'Dell    November 26, 2013 9:27 AM

VentureBeat: Security and privacy has been the hottest topic this year, bar none. We’ve heard rumors that Linus [Torvalds, Linux creator] OK’d a Linux backdoor for the government.

Zemlin: If there were a backdoor in Linux, you’d know it.

The whole world can see every line of code in Linux. This is one of the reasons Linux is more secure than other operating systems and why open-source software overall is a safer than closed software. The transparency of the code ensures it’s secure.

And for the record: He wasn’t approached.

Father says Linus was approached:

"When my oldest son [Linus Torvalds] was asked the same question: “Has he been approached by the NSA about backdoors?” he said “No”, but at the same time he nodded. Then he was sort of in the legal free. He had given the right answer …everybody understood that the NSA had approached him."

Did Linus Torvalds backdoor Linux random number generation?:-
"Two years ago Linus overrode a decision by the maintainer of /dev/random and made a decision to include a patch by Intel which would make Linux rely blindly on output from RdRand (an implementation sealed in a chip and impossible to audit)
Matt Mcall, the maintainer of the Linux RNG was so appalled by this decision that he felt that he had no alternative but to quit the project." :-
Matt Mackall, the former maintainer of /dev/random, actually stepped down over this issue, because Linus overrode Matt and applied Intel's patch that used their hardware random number generator directly:

Ted Ts'o later reverted this, separating out Intel's hardware random number generation into a separate function that could be used to seed the entropy pool but wouldn't be trusted directly as the main kernel source of random numbers:
"If I had to guess what happened, some intel people pushed this as a feature, probably pushing it via one of the x86 git trees, and Linus either (a) didn't notice, or (b) didn't understand the implications, and then Matt quit in a huff --- by just stopping to do work, and not even updating the entry in the MAINTAINERS file."

 tytso 1199 days ago [-]
Not only did it happen before, just TODAY I had to fight back an attempt by a Red Hat engineer who wanted to add a configuration option which would once again allow RDRAND to be used directly, bypassing the entropy pool:

"It's unlikely that Intel (for example) was paid off by the US Government to do this, but it's impossible for them to prove otherwise --- especially since Bull Mountain is documented to use AES as a whitener. Hence, the output of an evil, trojan-horse version of RDRAND is statistically indistinguishable from an RDRAND implemented to the specifications claimed by Intel. Short of using a tunnelling electronic microscope to reverse engineer an Ivy Bridge chip and disassembling and analyzing the CPU microcode, there's no way for us to tell for sure." :-
Technology companies maintain that they work with the intelligence agencies only when legally compelled to do so.

The Guardian has previously reported that Microsoft co-operated with the NSA to circumvent encryption on the email and chat services.  
The company insisted that it was obliged to comply with "existing or future lawful demands" when designing its products.

The IPbill just brings this point out into the open.

Thursday, 15 December 2016

Is Linux being helped or hijacked by corporate involvement?

Is Linux being helped or hijacked by corporate involvement? AKA has Linux lost its way?
Who knows, but here are some thoughts:
Linux started as a student project and gathered an enthusiastic band of volunteers …..but look at it now.
“The Linux kernel is growing and changing faster than ever, but its development is increasingly being supported by a select group of companies, rather than by volunteer developers.
That’s according to the latest survey of Linux kernel of development by the Linux Foundation, which it published to coincide with the kickoff of this year’s Linux Foundation Collaboration Summit on Wednesday.
Whether the decline in volunteer code contributions since Linux’s early days is actually a bad thing, however, is open to debate.
For one thing, kernel development is something of a rarified skill, and coders who successfully submit patches probably won’t stay unemployed for long. Now they’re volunteers; now they aren’t.
Also, the Linux kernel has hardly been taken over by some Good Ol’ Boys network of top IT companies. One developer who consistently makes the list of top kernel contributors, for example, is H Hartley Sweeten of Vision Engraving Systems, a maker of industrial engraving equipment.
Similarly, the Linux Foundation announced on Wednesday that its latest member is media giant Bloomberg, which has joined as Gold member and says it will “continue to take on a more prominent role in the broader community development and collaboration behind Linux.”

from the comments on this page:
Is this trend isolated or common?
Date: 2016-01-22 11:51 pm (UTC)
From: (Anonymous)
So far I count:
– Linux Foundation quietly dropped community representation:-
– The Radeon related conspiracies (I didn’t look at it in depth yet).
– The libusb related conspiracy (See Peter Stuge’s talk at 32C3).
– The foundation corporate membership limit change attempt.
Is there other examples of such patterns that I missed?
Are theses isolated incidents? Or are they part of a bigger picture?
If it is, I can only think of corporate control over free software projects, but why?
I guess free software companies wouldn’t benefit from it.
However I think that the proprietary software companies would. They nowadays depend on free software so they can’t kill it, they probably don’t want to either.
However controlling the associations and leveraging such control could be used to help prevent free software from replacing their proprietary products.
Here I’m only wondering if something is happening, and I don’t have any answers.

Link Reply Thread Hide 1 comment
Re: Is this trend isolated or common?
Date: 2016-01-23 12:18 am (UTC)
From: (Anonymous)
Free software has always been a threat to the “capitalist” business model espoused by the big corporations. This model has no room for products that threaten their high profit margins, so they always attempt to buy or hijack the problem people and products. An example from the dark side is Mark Russinovich being bought off by Microsoft after the Sony rootkit affair.
Another way to look at the Linux Foundation is that we have isolated the problem to a small place and made the corporates pour their money into a different rat hole, but we have to act on that approach, perhaps by forking the kernel and making the community version the important one, removing the Linux Foundation’s influence over the real world by simple community action.
While this approach would seem cruel in that Torvalds would be shorn of his halo, in fact devolving the “governance” of the Linux kernel would serve as a way of keeping him honest, and potentially improve the overall product. Just like all of the MySQL forks forced Oracle to be honest, so would a hurd of Linux forks force “Linux” back to the real world. :-
People like Linus Torvalds and I don’t plan the kernel evolution. We don’t sit there and think up the roadmap for the next two years, then assign resources to the various new features. That’s because we don’t have any resources. The resources are all owned by the various corporations who use and contribute to Linux, as well as by the various independent contributors out there. It’s those people who own the resources who decide…
— Andrew Morton, 2005
Linux is evolution, not intelligent design
— Linus Torvalds, 2005[122][123]
“The real question behind the debate, as I see it, is who controls The Linux Foundation? The users or the companies?
Garrett sees this move as The Linux Foundation taking one more step away from the community and towards the corporate world. Zemlin doesn’t address this point specifically but, tellingly, he does say that the “process for recruiting community directors should be changed to be in line with other leading organizations in our community and industry.”
In addition, as Garrett pointed out, individuals no longer longer have “The ability to run for and vote for a Linux Foundation board seat and influence the direction of the foundation.”
Personally, I see this as a move towards more corporate control of the Foundation. But, as the saying goes, who pays the piper calls the tune. I find nothing surprising about this move.
While open-source users love the concept of community, the “community” has been made up of corporate executives and employees for well over a decade now. Only the most idealistic open-source developer and leaders and, ironically, open source’s most fervent enemies still think of Linux and open-source projects being created and controlled by private individuals.
Besides, the overwhelming majority of The Linux Foundation board of directors has always been made up of corporately chosen directors. Still, this Linux Foundation decision rubs me the wrong way. Linux started as an individual’s project that quickly gathered the support of many bright programmers. There should always be a place for individuals rather than corporations to have their say in The Linux Foundation’s leadership.
I hope Sandler, who is a strong, brilliant open-source leader, not only is allowed to run for office, but wins a place on the board. I also hope the Foundation restores the right for individuals to vote and run for office on the board. This is not asking for much, and it would restore faith that the Foundation still has room left for the little people and not just the big companies.”
“They” tried, for years, to destroy Linux. “Only hackers use it”, “only hippies use it”, “only communists or terrorists use it”, “we own patents for most of it” and each one failed. Now they’re attacking it from within and it’s worked beautifully. One community torn asunder over systemd. Most distros now firmly in the palm of Red Hat and thus under their control. The modularity and control that distinguished Linux from other OS’s, now mostly gone and by the time Poettering has finished, it will all be gone. And then it will be too late.
Thankfully there are still some distros holding out – Slackware, Crux, Pisi, Manjaro OpenRC and Devuan if it gets off the ground. Long may they continue to resist. But I don’t hold out much hope in the long run. This is Corporate takeover 101 and so few even see what’s happening that the chances of stopping it are next to zero. Sad.
A cornerstone of Linux’s success is its huge user community. Since 2005, some 11,800 individual developers from nearly 1,200 different companies have contributed to the kernel, the Linux Foundation says. Linux is the largest collaborative development project in history and it is being developed faster than any other software in the world.
And now Linux is accelerating tech innovation via open collaboration at all levels – from the chip and on up through the entire hardware and software stacks.
Ultimately, open source isn’t about code. It’s about community, and as Bert Hubert suggests, “community is the best predictor of the future of a project.” That community isn’t fostered by jerk project leads or corporate overlords pretending to be friendly foundations. It’s the heart of today’s biggest challenges in open source — as it was in the last decade.
The Linux model inspired IBM, NVIDIA, Mellanox, Google, and Tyan to create the OpenPOWER initiative in December 2013. OpenPOWER does for hardware what Linux has done for software: makes it free and open source
it has become increasingly common for companies to maintain control of important open source tools.
That can make for more efficient decision making. But as we’ve seen with Node, it can also lead to tensions between the parent company and outside developers who adopt and develop the technology. How the Node community deals with these tensions could set important precedents for how other important open source technologies, such as the cloud computing tool Docker, are managed.

Tuesday, 1 November 2016

Virtualbox headless

Virtualbox headless

1. To start Virtualbox headless

To start vboxweb from non-root user you must:

1.1. Create or add a user in the group vboxusers (for example, user)

sudo usermod -a -G vboxusers user
The -G switch takes a (comma-separated) list of supplementary groups to assign the user to. The -a (append) switch is important, otherwise the user will be removed from any groups not in the list.
The user will need to logout and log back in to see their new group added.

1.2. Create your custom vboxweb_mod.service file by copying /lib/systemd/system/vboxweb.service to /etc/systemd/system/vboxweb_mod.service

sudo cp /lib/systemd/system/vboxweb.service /etc/systemd/system/vboxweb_mod.service

1.3. Modify /etc/systemd/system/vboxweb_mod.service to this:

[Unit] Description=VirtualBox Web Service

[Service] Type=forking
ExecStart=/usr/bin/vboxwebsrv --pidfile /run/vboxweb/ --host= --background



1.4. Create tmpfile rule for your vboxweb_mod.service

sudo echo “d /run/vboxweb 0755 vbox vboxusers” > /etc/tmpfiles.d/vboxweb_mod.conf

1.5. Manually create the /run/vboxweb directory for first start vboxweb_mod.service

sudo mkdir /run/vboxweb
sudo chown user:vboxusers /run/vboxweb
sudo chmod 755 /run/vboxweb

1.6. Start/enable with:

sudo systemctl enable vboxweb_mod.service
The service will now run on startup.

1.7. To disable the service:

sudo systemctl disable vboxweb_mod.service

check if service is listening

sudo netstat -nap | grep vboxwebsrv

Monday, 31 October 2016

cisco how to save config

how to save config

Forum links

Clear Existing Configurations on the Cisco DSL Router

Complete these steps:
  1. Type enable at the router prompt to enter privileged mode.
    !--- The # symbol indicates that you are in privileged mode.
  2. Clear existing configurations on the router.
    Router#write erase
  3. Reload the router so it boots with a blank startup configuration.
    System configuration has been modified. Save? [yes/no]:no
    Proceed with reload? [confirm]yes
    !--- Reloading the router can take a few minutes.

  4. After the router has reloaded, enter enable mode again.

    Use a Terminal Emulation Program to Backup and Restore a Configuration

    A terminal emualation program can be used to back up and restore a configuration.This is a description of the procedure using Microsoft Hyperterminal Terminal Emulation software:
    1. If the configuration needs to be copied from another router, connect to that router through the console or Telnet.
    2. At the Router> prompt, issue the enable command, and provide the required password when prompted.
      The prompt changes to Router#, which indicates that the router is now in privileged mode.
    3. Issue the terminal length 0 command in order to force the router to return the entire response at once, rather than one screen at a time.
      This allows you to capture the configuration without extraneous --more-- prompts generated when the router responds one screen at a time.
    4. On the HyperTerminal menu, choose Transfer > Capture Text.
      The Capture Text window appears.
    5. Name this file "config.txt."
    6. Click Start in order to dismiss the Capture Text window and begin the capture.
    7. Issue the show running-config command, and allow time for the router to complete its response. You will see:
      Building configuration...
      followed by the configuration.
    8. On the HyperTerminal menu, choose Transfer > Capture Text > Stop in order to end the screen capture.
    9. Open the config.txt file you created in any text editor, such as Notepad or Wordpad.
    10. Search for and remove any line that starts with "AAA".
      Note: This step is to remove any security commands that could lock you out of the router.
    11. Save the file.
    12. Connect to the router that needs the configuration.
    13. Open the config.txt file.
    14. Highlight the entire contents of the config.txt file.
      You can do this by dragging the cursor from before the first character to after the last character in the file while holding down the left mouse button. Alternatively, if you use Notepad, you can choose Edit > Select All from the menu.
    15. Copy the selected text to the Windows clipboard.
      You can either choose Edit > Copy from the text editor menu, or hold down theCTRL key and simultaneously press the C key in order to perform the copy.
    16. Switch to the HyperTerminal window, and issue the configure terminal command at the Router# prompt. Then press Enter.
    17. Paste the configuration file into the router by selecting Edit > Paste to Host on the HyperTerminal menu.
    18. After the configuration has finished pasting and the router brings you back to the configuration prompt, issue the copy running-config startup-config command in order to write the configuration into memory.
    19. Issue the exit command in order to return to the Router# prompt.

     For PPPoA

    interface ATM0
    no ip address
    atm ilmi-keepalive
    pvc 0/16 ilmi
    pvc 8/35
    encapsulation aa15mux ppp dialer
    dialer pool-member 1

    For PPPoE

    interface ATM0
    no ip address
    atm ilmi-keepalive
    pvc 0/16 ilmi
    pvc 8/35
    protocol pppoe
    pppoe-client dial-pool-number 1

Tesco settings
VPI = 0

VCI = 38

ADSL Modulation Auto, then try G.DMT, then try ANSI T1.413

Encapsulation Mode PPP over ATM (PPPoA - RFC2364) VC-MUX

Service name Home 500

Authentication CHAP 

MTU = 1458

Receive Window (RWIN)

The formula for finding your "ideal" RWIN, is to take your latency (average ping time in ms x 1.5), multiply that by your advertised (download) speed, and divide that by 8. 

Note: If setting RWIN below 8192, try using even multiples of MSS.'


example config

no service pad 
                service timestamps debug uptime
                service timestamps log uptime
                service password-encryption
                hostname router
                logging buffered 4096 debugging
                ip name-server <Name Server 1> <Name Server 2>
                ip subnet-zero
                ip dhcp excluded-address
                ip dhcp excluded-address
                ip dhcp pool dhcppool
                  import all
                  dns-server <Name Server 1> <Name Server 2>
                clock timezone NZST 12
                clock summer-time NZDT recurring 1 Sun Oct 2:00 3 Sun Mar 3:00
                interface Ethernet0
                  ip address
                  ip nat inside
                interface ATM0
                  no ip address
                  no atm ilmi-keepalive
                  dsl operating-mode auto
                interface ATM0.1 point-to-point
                  pvc 0/100
                    encapsulation aal5mux ppp dialer
                    dialer pool-member 1
                interface Dialer0
                  bandwidth 640
                  ip address negotiated
                  no ip redirects
                  no ip unreachables
                  ip nat outside
                  encapsulation ppp
                  dialer pool 1
                  dialer-group 1
                  ppp pap sent-username <username> password <password>
                  ppp ipcp dns request
                  no cdp enable
                ip nat
                inside source list 1 interface Dialer0 overload
                ip classless
                ip route Dialer0
                no ip http server
                banner motd |Orignal config (c)IFM Ltd, prepared by IFM Ltd/|
                line vty 0 4
                  access-list 1 in
                access-list 1 permit
                dialer-list 1 protocol ip permit

Some things you might consider:
-global commands-
no snmp-server
no ip identd
no ip bootp server
no ip source-route
no ip gratuitous-arps
no ip directed-broadcast
no ip domain-lookup
no ip http server
no ip http secure-server
no cdp run
service tcp-keepalives-in
service tcp-keepalives-out
service sequence-numbers
login on-failure log
login on-success log
login block-for 60 attempts 3 within 30
-use ssh only to connect to router, if possible force version 2 and put access list to restrict vty access
ip ssh version 2
line vty 0 4
transport input ssh
- on interfaces use the following -
no ip redirects
no ip unreachables
no ip proxy-arp
no ip directed-broadcast
no cdp enable
ntp disable
- to disable common ip vulnerabilities
Beyond that, set up good logging and a trusted time source. Also, access lists to filter packets that should not be entering an interface, for example on int e0 block all but, depending on how paranoid you want to be. On external interface block private networks, loopback, multicast, etc.