text:
# etap

Extremely simple header only library for creating single file test executables that emit Test Anything Protocol (TAP) to stdout.

The tests can be written using simple MACROS similar is flavour to google test, and the test file can be C or CPP.  The framework has a hook to allow initialisation of the target, to support embedded unit tests on real hardware.  These typically put their stdout on one of:
  *  semi-hosting via a JTAG dongle
  *  channel 0 on the SWO serial (Arm ITM/SWD serial out)
  *  a real physical serial port

# using
If you are using cmake you should be able to simply add this repo as a
submodule, then add the following to your top level CMakeLists.txt;
``` cmake
add_subdirectory(etap)
```
Then create tests by following the examples shown in the etap unittests
directory.  If you are writing tests for the desktop (POSIX, windows) you must
include the macro ETAP_DEFAULT_BSP somewhere in the body of your test file.  If
you are writing embedded unit tests you must provide the file with the signature
  > void etap_init_bsp(argc, argv);

This is to initialise your board, i.e. it is the "Board Support Package" call.
This is called exactly once by the framework before any of your tests are run.
The argc/argv are passed in so that your POSIX unit tests can get access to command
line arguments, to for instance map serial ports device names for hardware
driver unit tests that talk to real gear.

## converting TAP to junit style xml for Jenkins etc
There is a node package that will take TAP input on stdin and provide converted
junit style xml on stdout.  See;
  > https://www.npmjs.com/package/tap-junit

repository: methuselah-mayfly/etap

repo_name: methuselah-mayfly/etap


text:
---
layout: post
title: "Nested Nutanix CE 2.0 Deployment - Part 2"
excerpt: "Configuration and Test VM Build"
tags:
- Pro-Tip
- VMware
- Deployment
- ESXi
- Nutanix
image:
  thumb: /nested-nutanix-ce-deployment/nested-nutanix-ce-deployment-01.png
comments: true
date: 2023-03-28T00:00:00+00:00
---

In this post we will complete the basic configuration of our Nutanix AHV installation and deploy a VM into it.

This post is part 2 of a multipart series. Find the other parts here:

- Part 1: [Now it's Time for Something Different](/nested-nutanix-ce-deployment/){:target="_blank"}
- Part 2: This Part: Configuration and Test VM Build

Let's continue.

{% include _toc.html %}
## Configuration
Since part 1 covered purely the deployment of Nutanix CE 2.0, there are some post installation configuration points that we need to cover off prior to deploying our first guest VM later on in this post.

## CVM Certificate
So that we no longer need to tell chrome **thisisunsafe** each time we access our CVM, let's replace it's SSL certificate.

Click the settings cog in the top right hand corner of the PRISM Elements UI, select **SSL Certificate** from the menu on the left:

Select **Replace Certificate > Regenerate Self Signed Certificate** and **Apply**:

Allow time for the replacement to complete.  That's Chrome happy again!

## Change Default Credentials
Both our Host and our CVM are using the default credentials:

Clicking on each of the alarms in turn provides the following summaries:

And:

Let's fix that.

For reference, the Nutanix KB article that covers changing both the Host and CVM default credentials is here: [KB 6153](https://portal.nutanix.com/kb/6153){:target="_blank"}.

## Host Credentials
SSH to the AHV host as root (see [Part 1](/nested-nutanix-ce-deployment/#installing-vmware-tools){:target="_blank"} for default credentials) and issue the following command:
{% highlight shell %}
passwd
{% endhighlight %}

## CVM Credentials
SSH to the CVM as user nutanix (again see [Part 1](/nested-nutanix-ce-deployment/#ahv-vm-config){:target="_blank"} for default credentials)and issue the following command:
{% highlight shell %}
sudo passwd nutanix
{% endhighlight %}

Job done. Clicking on the alters and then clicking **Resolve** clears the alerts from the PRISM Element console.

## Storage Tier Skew on a Node

From Nutanix [KB 10718](http://portal.nutanix.com/kb/10718){:target="_blank"}:
> The NCC health check plugin node_storage_tier_skew_check reports disk capacity skew above 15% within a storage tier in each individual node in a Nutanix cluster.

As we have only the one host in our cluster, let's turn this check off. Click **Turn Check Off** to complete.

## Cluster Name
Let's name our cluster. Click on the label **Unnamed** and enter a cluster name and virtual IP:

Click **Save** when done.

The cluster FQDN needs to resolve to both the cluster virtual IP and to the CVM IP(s). I'm using OPNsense Unbound DNS in my lab, so to achieve this simply add two cluster FQDN host overrides pointing to the virtual and CVM IPs:

Nice:

## Language  Settings
Select **admin** in the top right hand corner of the PRISM Element UI and select **Update Profile**:

Enter name and email address, hit **Save** when done:

Click the settings cog in the top right hand corner of the PRISM Elements UI and select **Language Configuration**. Set Region accordingly and hit **Save**:

## Networking
Next we will create a network to connect our VMs to.

Click the settings cog in the top right hand corner of the PRISM Elements UI and select **Network Configuration** and **Subnets**:

Click **Create Subnet**.

I'll name my subnet **Site-A-Lab**, select vSwitch **vs0** and set my VLAN ID to **0** (native VLAN):

Click **Save** to complete. Job done:

## Upload ISOs
Next, we need to upload our operating system ISO. Whilst we are at it, we will also upload the Nutanix VirtIO for Windows ISO as well (VirtIO ISO can be downloaded from [HERE](https://next.nutanix.com/discussion-forum-14/download-community-edition-38417){:target="_blank"}).

Click the settings cog in the top right hand corner of the PRISM Elements UI, select **Image Configuration** from the menu on the left:

Select **Upload Image**. I'll upload my [Windows Server 2022 Evaluation ISO](https://info.microsoft.com/ww-landing-windows-server-2022.html){:target="_blank"}:

Allow time for the image to upload.  Repeat for the VirtIO ISO.

Once complete, confirm both ISOs are marked as **ACTIVE**, ready to use:

## VM Creation
Let's create our first (not counting the CVM) Nutanix guest VM then! :smile:

From the menu drop down select **VM** and **Create VM**:

I'll configure the following:

* Name: Win-Srv-2022
* Timezone: Europe / London
* vCPUs: 2
* Cores per vCPU: 1
* Memory: 2GB
* Legacy BIOS
* NIC: Connected to Site-A-Lab

Finally, I'll add a 60GB disk to my VM as follows:

Click **Save** to complete. Select **Table** to view the VM in the list.

## VM Power On and O/S Installation
Click **Power on** to start the VM and **Launch Console** to take a look at it:

Once the console of the newly created VM opens, select **Mount ISO**:

Select the O/S ISO uploaded earlier and select **Mount**:

The VM should boot from the ISO:

I won't cover the full installation of Windows here.

The only minor ripple to an otherwise normal Windows install was mounting the VirtIO ISO mid windows install to allow Windows to use the VirtIO SCSI controller driver:

Once the driver is loaded, hard disk discovered and selected, change the mounted ISO back to Windows and click **Refresh** within the Windows installer to get it to continue with the installation.

## VirtIO and Nutanix Guest Tools
Upon completion of the Windows installation, mount the VirtIO ISO again and launch the x64 installer:

Complete the install.

Back at the PRISM Element VM Table, select **Manage Guest Tools**:

I'm going to Enable and Mount the guest tools installer. I'll investigate the other options another day:

**Submit** to complete. Run the setup to install:

## Power Down
Because [UK Energy Crisis](https://www.google.com/search?q=uk+energy+crisis){:target="_blank"}, let's quickly cover safely powering down our Nutanix environment.

### CVM Shutdown
After shutting down all other guest VMs, SSH to the CVM and issue the command:
{% highlight shell %}
cvm_shutdown -P now
{% endhighlight %}

### AHV Host Shutdown
Cheat!

That's why we [installed VMTools in part 1](/nested-nutanix-ce-deployment/#installing-vmware-tools){:target="_blank"}. :wink:

## Conclusion and Wrap Up

So there we have it. In this post we built upon the [deployment of our Nutanix AHV host](/nested-nutanix-ce-deployment/){:target="_blank"} by completing it's configuration.

After that, we deployed a test VM. Finally we looked at how to power the environment down.

Nice!

This post is part 2 of a multipart series. Find the other parts here:

- Part 1: [Now it's Time for Something Different](/nested-nutanix-ce-deployment/){:target="_blank"}
- Part 2: This Part: Configuration and Test VM Build

-Chris

license: MIT

branch_name: refs/heads/master

extension: md

gha_language: HTML

gha_license_id: MIT

license_type: permissive


text:
# Scaffular - Angular Scaffolding

### This software was designed to save you development time and money
Did it help? Consider donating some of your savings towards further enhancements to the software!

[![patreon](https://c5.patreon.com/external/logo/become_a_patron_button.png)](https://www.patreon.com/bePatron?u=26073031)

### Summary

One of the toughest hurdles faced by Angular application developers is the "white screen of death"; it happens when you're just starting the project and haven't mapped it out fully --- or at all. You've installed all your packages, got the initial, empty project running; now you're staring at a white screen. What do you do now? Where do you start?

Scaffular helps by giving you a browser-based interface to scope out the project's routes, including forms and form fields, links that will be visible on that route's screen, and links that will be visible on all screens. This has the added benefit of allowing you to preview the project with stakeholders before development starts in earnest, providing them with a fast and interactive way to give feedback when it's most critical.

When you're satisfied that you have the project mapped out, a single `ng generate` command will register all your routes in app-router.module, register your components with app.module, update the outer app template with your defined global links, and generate component files and template files for each route, including route parameters, and reactive forms with all your fields. You can then `ng serve` the project and continue developing as you would normally.

### Getting Started

This tool uses the angular-cli command line tool, so you'll need to have it installed:
```
> npm i @angular/cli
```
Then go to the folder where you want your project created and type:
```
> ng new projectname
```
(Replace "projectname" with the actual name of your project)

Then move into the new project folder and add the scaffular planning UI:
```
> cd projectname
> ng add scaffular
```
You can then run `ng serve --open` to run the dev environment and load the page in your browser.

### Using the Planning Interface

#### Viewing the details of a defined route

When you're viewing a route that's been defined, you'll see the route address, a short description (if supplied), any forms with clickable submit buttons, any clickable exit links that are specific to that page, and any clickable exit links that are global to the entire application. You'll also see on the right hand side a set of buttons that let you edit the current route, export a copy of the project map in its current state, or reset the project map back to its defaults.

Clicking on one of the form buttons will show you a short description of what should take place when this form is submitted, along with a button to click on that will either navigate you to a new route, or take you back to the main view for the current one. You'll also see on the right hand side a button you can use to edit the current form.

Clicking on one of the page-specific exits or one of the global exits will either show you the details of the new route if it's defined, or show you the properties form if it's not.

#### Editing the properties of a route

The properties form for a route looks and acts the same for either editing an existing route or defining a new one. There's a text box to set the description of the route, a set of fields to define any forms, and then another set of fields to define any exit links.

When defining a form, you need to specify the button text as well as the name of the action that will happen when the form is submitted. The action name should be a string that is useable as a function name, such as "doNewsletterSignup". There's currently no validation for the field, so putting any other kind of text will most likely result in your project not compiling. The rows for defining forms will expand when you start typing on the last row, so you'll always be able to specify as many forms as needed. When editing a form, you can convert it to an exit or global exit by changing the value in the dropdown -- make sure you change the value of a form action to a route as well as changing the dropdown.

When defining an exit, use the dropdown to specify either global or route-specific, then specify the visible text for the link, and the route the user should be sent to after clicking. If you're editing a link, you can convert it to a global exit or a form by changing the value of the dropdown -- make sure you change the value of the route to a form action if you're changing a link to a form.

Hit the save button to save your changes and return to the details screen for the current route.

#### Editing the properties of a form

You can edit the forms of any route that's been defined by clicking on the form's submit button, and then clicking the edit button on the right hand side of the screen. You'll see a space you can use to explain what should happen when the user submits the form, as well as a space to enter the properties for one or more form fields.

Use the dropdown to specify the field's input type. You can also define a text label for the field, and a default value as well. For "select" type inputs, use commas in the value to generate the individual options in the select box. For example a select box with a label of "Country" might have a value of "USA,Canada,Etc,Etc". For "radio" or "checkbox" inputs, a comma-separated value will be used to generate the individual radio buttons or check boxes, with the label text for each option. When you start typing in the last row of fields, a new row will automatically be added so you should always have enough for your form.

There's also a field you can use to specify the route that the user should be navigated to after the actions of the form have been performed. Leave this field blank if you want the user to stay on the current route.

Hit the save button to save your changes and return the the details screen for the current form.

#### Exporting the Project Map

There's currently no mechanism by which the project map's JSON file can be updated automatically, so use the export button to download a copy of the file in its current state. You'll then need to use your computer's file manager to copy or move the file over top of the project map within your project. The map file is found at `src/app/scaffular/model/project.json`. Overwriting this file will automatically update the project the next time the page is refreshed in the browser. Note: these instructions are written assuming the development is happening on your local machine. You would need to use other file transfer methods if you were working remotely.

### Generating the Scaffolded Files

When you've completely defined the project's scope and are happy with everything, and you've saved over the project's JSON file with the exported file, you can quit the application by hitting Ctrl C in the command line. You'll then be able to type the following command:
```
> ng generate scaffular:ng-generate
```

This will update the existing app configurations to register your routes and components, and will automatically generate a component file and template for each of your routes. You should then simply need to `ng serve` to see your changes.

### Upcoming Enhancements

Development of Scaffular is ongoing, with some enhancements planned in the future. They include:

* A "preflight" screen that will let you look at the generator output of the project and alter some of the properties before running the generator
* A Node-based micro-service that will automatically save changes to your project map as you author, so you don't have to export it manually

repository: starkraving/scaffular

gha_language: TypeScript

repo_name: starkraving/scaffular


text:
# Mikrotik Router
![GitHub release (latest by date)](https://img.shields.io/github/v/release/tomaae/homeassistant-mikrotik_router?style=plastic)
[![hacs_badge](https://img.shields.io/badge/HACS-Default-orange.svg?style=plastic)](https://github.com/custom-components/hacs)
[![License](https://img.shields.io/github/license/tomaae/homeassistant-mikrotik_router?style=plastic)](LICENSE.md)
![Project Stage](https://img.shields.io/badge/project%20stage-development-yellow.svg?style=plastic)

![GitHub commits since latest release](https://img.shields.io/github/commits-since/tomaae/homeassistant-mikrotik_router/latest?style=plastic)
![GitHub commit activity](https://img.shields.io/github/commit-activity/m/tomaae/homeassistant-mikrotik_router?style=plastic)

Monitor and control your Mikrotik device from Home Assistant.
![Tracker and sensors](https://raw.githubusercontent.com/tomaae/homeassistant-mikrotik_router/master/docs/assets/images/ui/device_tracker.png)

![Interface Info](https://raw.githubusercontent.com/tomaae/homeassistant-mikrotik_router/master/docs/assets/images/ui/interface.png)
![Interface Switch](https://raw.githubusercontent.com/tomaae/homeassistant-mikrotik_router/master/docs/assets/images/ui/interface_switch.png)
![Interface Sensor](https://raw.githubusercontent.com/tomaae/homeassistant-mikrotik_router/master/docs/assets/images/ui/interface_sensor.png)
![Script Switch](https://raw.githubusercontent.com/tomaae/homeassistant-mikrotik_router/master/docs/assets/images/ui/script_switch.png)
![NAT switch](https://raw.githubusercontent.com/tomaae/homeassistant-mikrotik_router/master/docs/assets/images/ui/nat.png)

Features:
 * Interface device tracker
 * Enable/disable interface switches
 * Enable/disable NAT rule switches
 * RX/TX traffic sensors per interface
 * System sensors (CPU, Memory, HDD)
 * Firmware update binary sensor
 * Switches to run scripts

# Setup integration
Setup this integration for your Mikrotik device in Home Assistant via `Configuration -> Integrations -> Add -> Mikrotik Router`.
You can add this integration several times for different devices.

![Add Integration](https://raw.githubusercontent.com/tomaae/homeassistant-mikrotik_router/master/docs/assets/images/ui/setup_integration.png)
* "Host" - Use hostname or IP
* "Port" - Leave at 0 for defaults
* "Name of the integration" - Friendy name for this router

# Configuration
![Integration options](https://raw.githubusercontent.com/tomaae/homeassistant-mikrotik_router/master/docs/assets/images/ui/integration_options.png)
* "Show client MAC and IP" - Display connected IP and MAC address for devices connected to ports on router.
* "Scan interval" - Scan/refresh time in seconds. HA needs to be reloaded for scan interval change to be applied.

## List of detected devices
![Integration options](https://raw.githubusercontent.com/tomaae/homeassistant-mikrotik_router/master/docs/assets/images/ui/integration_devices.png)


text:
# Where can I find the download link?
First of all, you will need to download the purchased plugin from your CodeCanyon account. Login to [CodeCanyon](http://codecanyon.net), then navigate to your downloads page at [http://codecanyon.net/downloads](http://codecanyon.net/downloads). Click the __Download__ button to proceed.

![CodeCanyon Download](/resources/img/documentation/download-button.png)

#### I've downloaded the file. What's next?
Next, you need to extract the file. Go to your __Downloads__ folder or where you've saved the `.zip` file and extract it. The zip file should be named `codecanyon-18277446-volta-web-application-and-admin-dashboard.zip`. Depending on your operating system, you can extract a zip file in the following ways:

__macOS__
: Zip comes installed by default in __macOS__ and usually, zip files are extracted automatically upon download. If the zip file hasn't been extracted already when you downloaded it, simply double-click the file to extract it.

__Windows__
: You can either use 7Zip or the default Zip extractor depending on your __Windows__ version. To extract the zip file, right click it and __Extract All__.

__Linux__
: In Linux based operating systems you can use the unzip utility in your command line as follows: `unzip codecanyon-18277446-volta-web-application-and-admin-dashboard.zip -d volta`

repository: georgi-dev/dmr-academy

repo_name: georgi-dev/dmr-academy


text:
---
title: Getting The Necessitas To Port To Android
author: Andrew Wafaa
layout: post
kind: article
created_at: 2011-03-04
permalink: /getting-the-necessitas-to-port-to-android/
dsq_thread_id:
  - 593392736
categories:
  - Android
  - openSUSE
tags:
  - Porting
  - Qt
  - Software
---
#

So as I mentioned [earlier][1] I managed to port [entimologist][2] to Android. This post will hopefully explain how I did this.

 [1]: http://andrew.wafaa.eu/2011/03/04/bug-tracking-with-the-help-of-an-entomologist.html "Bug Tracking With The Help Of An Entomologist"
 [2]: http://entimologist.sourceforge.net/ "Entomologist Bug Tracking Client"

The shopping list for this task is relatively straight forward:

*   [Android SDK][3]
*   [Android NDK][4]
*   Java development files (on openSUSE I use java-1\_6\_0-sun-devel)
*   [ant][5] (on openSUSE ant is too old, I use the [binary tarball][6] from the Apache site)
*   Qt Creator for Android SDK a.k.a [Necessitas][7]
*   Not necessary but could be helpful – [Eclipse][8] (on openSUSE don’t use the packages available as there are things missing that prevent building for android, use the [binary tarball][9] from the Eclipse site)
*   [Ministro][10]

 [3]: http://developer.android.com/sdk/index.html "Android Software Development Kit"
 [4]: http://developer.android.com/sdk/ndk/index.html "Android Native Development Kit"
 [5]: http://ant.apache.org/ "Apache Ant"
 [6]: http://ant.apache.org/bindownload.cgi "Grab the latest binary tarball"
 [7]: https://sourceforge.net/p/necessitas/home/ "Qt Creator for Android"
 [8]: http://www.eclipse.org/ "Java IDE"
 [9]: http://www.eclipse.org/downloads/packages/eclipse-ide-java-developers/heliossr2 "Grab the binary tarball"
 [10]: https://sourceforge.net/projects/ministro.necessitas.p/files/ "Qt libraries for Android"

First thing I had done was install and setup Eclipse, I then setup the Android SDK & Android NDK – that was done months ago. See the Android Developer site for good, clear instructions.

For setting up Necessitas, I used Alessandro’s [post & video][11] as a guide, but there are also details on Necessitas’ site.  After following the steps, I couldnt quite get things working, and I was starting to think that GNOME3 and Qt, were being children and bickering. No, they weren’t. It was me being a dufus! I hadn’t read the bit about ant needing to be >=1.8.0 :-) Download Ministro to somewhere safe (I popped mine in /opt/necessitas)

 [11]: http://labs.qt.nokia.com/2011/02/28/necessitas/ "Clear instructions for Necessitas"

So to get things to work, I un-installed the ant rpm, extracted the bibnary tarball into ~/bin, and did a `sudo ln -s ~/bin/apache-ant-1.8.2/bin/ant /usr/bin/ant`

Now I wont pretend to know WTF I’m doing with Qt, as far as I’m concerned it’s another alien language. Problem is I needed to tell Necessitas what Qt libraries entomologist needed, I had no real idea. I had a look at the source and the spec file and got some clues, so I added the ones I thought were needed. I tried a build and got further than previously (now that I had the correct version of ant!). I was now getting some weird missing library error, but I couldn’t work it out. Along comes our new [Boosters][13] member [Ismail Dönmez][14] to the rescue.  There will be a lib$APPNAME.so that is created to work out which Qt libraries you need just do a `readelf -d  lib$APPNAME.so`.

 [13]: http://en.opensuse.org/openSUSE:Boosters_team "The Thirsty Thirteen"
 [14]: http://namtrac.org/ "a.k.a cartman or divildivil"

In my case I did `readelf -d libentomologist.so` and got:

`~/workspace/Entomologist-build-android> readelf -d libentomologist.so`

`Dynamic section at offset 0x4bda8 contains 29 entries:`

`  Tag        Type                         Name/Value`

` 0x00000001 (NEEDED)                     Shared library: [libQtSql.so]`

` 0x00000001 (NEEDED)                     Shared library: [libQtXml.so]`

` 0x00000001 (NEEDED)                     Shared library: [libQtGui.so]`

` 0x00000001 (NEEDED)                     Shared library: [libQtNetwork.so]`

` 0x00000001 (NEEDED)                     Shared library: [libQtCore.so]`

` 0x00000001 (NEEDED)                     Shared library: [liblog.so]`

` 0x00000001 (NEEDED)                     Shared library: [libz.so]`

` 0x00000001 (NEEDED)                     Shared library: [libdl.so]`

` 0x00000001 (NEEDED)                     Shared library: [libm.so]`

` 0x00000001 (NEEDED)                     Shared library: [libc.so]`

` 0x0000000e (SONAME)                     Library soname: [libentomologist.so]`

` 0x00000010 (SYMBOLIC)                   0x0`

` 0x0000000f (RPATH)                      Library rpath: [/system/lib/data/data/eu.licentia.necessitas.ministro/files/qt/lib]`

` 0x00000019 (INIT_ARRAY)                 0x4c04c`

` 0x0000001b (INIT_ARRAYSZ)               8 (bytes)`

` 0x00000004 (HASH)                       0xd4`

` 0x00000005 (STRTAB)                     0x7d18`

` 0x00000006 (SYMTAB)                     0x2638`

` 0x0000000a (STRSZ)                      48318 (bytes)`

` 0x0000000b (SYMENT)                     16 (bytes)`

` 0x00000003 (PLTGOT)                     0x4ceb0`

` 0x00000002 (PLTRELSZ)                   5720 (bytes)`

` 0x00000014 (PLTREL)                     REL`

` 0x00000017 (JMPREL)                     0x154e8`

` 0x00000011 (REL)                        0x139d8`

` 0x00000012 (RELSZ)                      6928 (bytes)`

` 0x00000013 (RELENT)                     8 (bytes)`

` 0x6ffffffa (RELCOUNT)                   307`

` 0x00000000 (NULL)                       0x0`

It may seem obvious, but look at the ones that have (NEEDED) in them ;-) I was missing libQtXml.so. Simply add the missing Qt library either by adding it manually in $PROJECT_LOCATION > Other files > android > res > values > libs.xml, or simply tick the required one in Qt Creator by going to the Projects button on the left > Run > Package Configurations > Libraries tab

When testing your app, make sure you select “Install Ministro system wide qt shared libraries installer” from the Projects button on the left > Run > Deploy configurations, then select the .apk in the “Choose apk” button.

Once that’s done, hit the “Play” button on the bottom left of Qt Creator and off you go :-)  I appreciate it may seem like a lot of work, but honestly it isn’t that much. I buggered around for ages cursing, mainly because I hadn’t checked my version of ant and didnt read the error message being spat out. I also didn’t know about readelf -d.  All I need to work out and try now is publishing to the Market https://market.android.com/. So all in all have fun and keep being cute Qt :-D

repository: awafaa-zz/EuropeanWafaa

repo_name: awafaa-zz/EuropeanWafaa


text:
---
id: bsk:getting-started
title: Getting Started ∙ actions-interactor
---

# Getting Started

For better experience, make sure that you have `npm v3+` installed. Start by cloning this repo and
installing project dependencies:

```sh
$ git clone -o actions-interactor \
      -b master --single-branch \
      https://github.com/AdrienEtienne/actions-interactor.git \
      <your-project-name>
$ cd <your-project-name>
$ npm install
```

### How to Build

Running `npm run build` will compile source files to a distributable format (CommonJS, ES6 and UMD)
ready to be published to NPM from the `dist` folder. See `tools/build.js` for more info.

### How to Test

Run one, or a combination of the following commands to lint and test your code:

* `npm run lint`       — lint the source code with ESLint
* `npm test`           — run unit tests with Mocha
* `npm run test:watch` — run unit tests with Mocha, and watch files for changes
* `npm run test:cover` — run unit tests with code coverage by Istanbul

### How to Update

Down the road you can fetch and merge the recent changes from this repo back into your project:

```sh
$ git checkout master
$ git fetch actions-interactor
$ git merge actions-interactor/master
$ npm install
```

repository: AdrienEtienne/actions-interactor

repo_name: AdrienEtienne/actions-interactor


text:
# Book App

**Author**: Natalie Sinner and Bhagirath Bhatt

**Version**: 1.0.0 (increment the patch/fix version number if you make more commits past your first submission)

## Overview
This week, you and your partner(s) will implement a basic full-stack application for a book list which will include the ability to search the Google Books API, add books to a database, and then render those books from a PostgreSQL database. You will also add the ability to update the details of a book or remove it from the collection.

Today’s portion of the application involves requesting books from the API. The client can submit a form to search for a book by title or author, and the search results will then be rendered as a list in the browser.

Your entire application will be deployed on Heroku.

## Getting Started
Create a new repository on GitHub named book_app. Add your partner as collaborator. Clone this repository into your 301 directory. You will be working in this same repository for labs 11 through 14.

## Architecture
- Understand how to architect a full-stack web application
- Create a schema to model data
- Interact with the Google Books API to search for books based on user queries
- Display API results to the user, hiding certain details for a smooth user experience
- Be able to dynamically render information to the user through the use of a server-side templating library
- Heroku App: https://ns-bb-booklist.herokuapp.com/

## Change Log
04-27-2020 - Application now has a fully-functional express server, with GET and POST routes for the book resource.

           - Steps 1-4 of Trello board complete.

## Credits and Collaborations
<!-- Give credit (and a link) to other people or resources that helped you build this application. -->
-->


text:
Description
===========

A cookbook to deploy a Django application running on EC2 with an external Postgres server also running on EC2.

Requirements
============

See metadata.rb

Usage
=====

Use as part of [the Definitive Guide to Django Deployment](https://github.com/rogueleaderr/definitive_guide_to_django_deployment).


text:
# TODO

 - [ ] Load content tree
 - [ ] Write documentation in docs/ as example project
 - [ ] Render directory listings
 - [ ] Render category listings
 - [ ] Render content files

# BACKLOG

 - [ ] Add content support for Markdown (blackfriday)
 - [ ] Add content support for HAML (DataDrake/haml
 - [ ] Add content support for TimberText (DataDrake/TimberText)
 - [ ] Add template support for HAML (DataDrake/haml
 - [ ] Add RSS feed generation for content/blog
 - [ ] Add RSS feed generation for podcasts
 - [ ] Add metadata fields to content for RSS
 - [ ] Add fields to config for RSS

# COMPLETED

 - [x] Add comments to everything (golint)
 - [x] Load configuration tree
 - [x] Load template tree
 - [x] Add content support for HTML
 - [x] Add template support for Go html/template
 - [x] Put static-cling on github

repository: ionutnechita/datadrake-static-cling

repo_name: ionutnechita/datadrake-static-cling


text:
# Insiticia flavovirens (Sacc.) E. Horak ex Segedin, 1987 SPECIES

#### Status
ACCEPTED

#### According to
The Catalogue of Life, 3rd January 2011

#### Published in
N. Z. Jl Bot. 25(2): 197 (1987)

#### Original name
Mycena flavovirens Sacc., 1891

### Remarks
null

repository: mdoering/backbone

repo_name: mdoering/backbone


text:
#### Its a Django application system should pre install the python to run this application

##### There is a setup shell script is available in the project directory, I have make it according to mac, in case it is not working please follow the steps below. Run following command in project directory to make it run
    sh setup.sh

##### Install virtual env
    python3 -m pip install --user virtualenv

##### Install virtual env
    virtualenv assignment
##### Activate virtual env
    source assignment/bin/activate

##### Install project dependencies
    pip3 install -r requirement.txt

##### Running unittest cases
    python manage.py test

##### Running the application
    python manage.py runserver

license: Unlicense

repository: avirepo/SendderAssignment

branch_name: refs/heads/main

repo_name: avirepo/SendderAssignment


text:
**Table of Contents**

- [Quickstart](#quickstart)
- [Compatibility with v2](#compatibility-with-v2)
- [Goals](#goals)
- [Features](#features)
- [The Docker Way?](#the-docker-way)
- [Init stages](#init-stages)
- [Installation](#installation)
- [Usage](#usage)
  - [Using `CMD`](#using-cmd)
  - [Writing a service script](#writing-a-service-script)
  - [Setting the exit code of the container to the exit code of your main service](#setting-the-exit-code-of-the-container-to-the-exit-code-of-your-main-service)
  - [Fixing ownership and permissions](#fixing-ownership-and-permissions)
  - [Executing initialization and finalization tasks](#executing-initialization-and-finalization-tasks)
  - [Writing an optional finish script](#writing-an-optional-finish-script)
  - [Logging](#logging)
  - [Dropping privileges](#dropping-privileges)
  - [Read-only Root Filesystem](#read-only-root-filesystem)
  - [Container environment](#container-environment)
  - [Customizing s6-overlay's behaviour](#customizing-s6-overlay-behaviour)
  - [syslog](#syslog)
- [Performance](#performance)
- [Verifying Downloads](#verifying-downloads)
- [Notes](#notes)
- [Releases](#releases)
  - [Which architecture to use depending on your TARGETARCH](#which-architecture-to-use-depending-on-your-targetarch)
- [Contributing](#contributing)
- [Building the overlay yourself](#building-the-overlay-yourself)
- [Upgrade notes](#upgrade-notes)

# s6-overlay [![Build Status](https://api.travis-ci.org/just-containers/s6-overlay.svg?branch=master)](https://travis-ci.org/just-containers/s6-overlay)

s6-overlay is an easy-to-install (just extract a tarball or two!) set of scripts and utilities
allowing you to use existing Docker images while using [s6](https://skarnet.org/software/s6/overview.html)
as a pid 1 for your container and process supervisor for your services.

## Quickstart

Build the following Dockerfile and try it out:

```
# Use your favorite image
FROM ubuntu
ARG S6_OVERLAY_VERSION=<IP_ADDRESS>

RUN apt-get update && apt-get install -y nginx xz-utils
RUN echo "daemon off;" >> /etc/nginx/nginx.conf
CMD ["/usr/sbin/nginx"]

ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz
ENTRYPOINT ["/init"]
```

```
docker-host $ docker build -t demo .
docker-host $ docker run --name s6demo -d -p 80:80 demo
docker-host $ docker top s6demo acxf
PID                 TTY                 STAT                TIME                COMMAND
11735               ?                   Ss                  0:00                \_ s6-svscan
11772               ?                   S                   0:00                \_ s6-supervise
11773               ?                   Ss                  0:00                | \_ s6-linux-init-s
11771               ?                   Ss                  0:00                \_ rc.init
11812               ?                   S                   0:00                | \_ nginx
11814               ?                   S                   0:00                | \_ nginx
11816               ?                   S                   0:00                | \_ nginx
11813               ?                   S                   0:00                | \_ nginx
11815               ?                   S                   0:00                | \_ nginx
11779               ?                   S                   0:00                \_ s6-supervise
11785               ?                   Ss                  0:00                | \_ s6-ipcserverd
11778               ?                   S                   0:00                \_ s6-supervise
docker-host $ curl --head http://<IP_ADDRESS>/
HTTP/1.1 200 OK
Server: nginx/1.18.0 (Ubuntu)
Date: Mon, 17 Jan 2022 13:33:58 GMT
Content-Type: text/html
Content-Length: 612
Last-Modified: Mon, 17 Jan 2022 13:32:11 GMT
Connection: keep-alive
ETag: "61e56fdb-264"
Accept-Ranges: bytes

```

## Compatibility with v2

If you're migrating from a previous version of s6-overlay (*v2*) to the
new version (*v3*), you may need to make some changes to your services
or the way you use s6-overlay in order for everything to work smoothly.
This document tries to be accurate on how v3 works, but we have a
[separate page](https://github.com/just-containers/s6-overlay/blob/master/MOVING-TO-V3.md)
listing the main differences, and things you're likely to notice. Please
read it if you're in this situation!

## Goals

The project has the following goals:

* Be usable on top of *any* Docker image
* Make it easy to create new images, that will operate like any other images
* Provide users with a turnkey s6 installation that will give them a stable
pid 1, a fast and orderly init sequence and shutdown sequence, and the power
of process supervision and automatically rotated logs.

## Features

* A simple init process which allows the end-user to execute tasks like initialization (`cont-init.d`),
finalization (`cont-finish.d`) and their own services with dependencies between them
* The s6-overlay provides proper `PID 1` functionality
  * You'll never have zombie processes hanging around in your container, they will be properly cleaned up.
* Multiple processes in a single container
* Able to operate in "The Docker Way"
* Usable with all base images - Ubuntu, CentOS, Fedora, Alpine, Busybox...
* Distributed as a small number of .tar.xz files depending on what exact functionality you need - to keep your image's number of layers small.
* A whole set of utilities included in `s6` and `s6-portable-utils`. They include handy and composable utilities which make our lives much, much easier.
* Log rotating out-of-the-box through `logutil-service` which uses [`s6-log`](https://skarnet.org/software/s6/s6-log.html) under the hood.
* Some support for Docker's `USER` directive, to run your whole process tree as a specific user. Not compatible with all features, details in the [notes](#notes) section.

## The Docker Way?

One of the oft-repeated Docker mantras is "one process per container", but we disagree.
There's nothing inherently *bad* about running multiple processes in a container.
The more abstract "one *thing* per container" is our policy - a container should do one thing,
such as "run a chat service" or "run gitlab." This may involve multiple processes, which is fine.

The other reason image authors shy away from process supervisors is they believe a process supervisor
*must* restart failed services, meaning the Docker container will never die.

This does effectively break the Docker ecosystem - most images run one process that will
exit when there's an error. By exiting on error, you allow the system administrator to
handle failures however they prefer. If your image will never exit, you now need some
alternative method of error recovery and failure notification.

Our policy is that if "the thing" fails, then the container should fail, too.
We do this by determining which processes can restart, and which should bring down
the container. For example, if `cron` or `syslog` fails, your container can most
likely restart it without any ill effects, but if `ejabberd` fails, the container
should exit so the system administrator can take action.

Our interpretation of "The Docker Way" is thus:

* Containers should do one thing
* Containers should stop when that thing stops

and our init system is designed to do exactly that.

See "Writing an optional finish script" under the [Usage](#usage) section for details on stopping "the thing."

## Init stages

Our overlay init is a properly customized one to run appropriately in containerized environments.
This section briefly explains how stages work but if you want to know how a complete init system
should work, you can read this article: [How to run s6-svscan as process 1](https://skarnet.org/software/s6/s6-svscan-1.html)

1. **stage 1**: Its purpose is to set up the image to execute the supervision tree which
will handle all the auxiliary services, and to launch stage 2. Stage 1 is where all the
black magic happens, all the container setup details that we handle for you so that you don't
have to care about them.
2. **stage 2**: This is where most of the end-user provided files are meant to be executed:
    1. Execute legacy oneshot user scripts contained in `/etc/cont-init.d`.
    2. Run user s6-rc services declared in `/etc/s6-overlay/s6-rc.d`, following dependencies
    3. Copy legacy longrun user services (`/etc/services.d`) to a temporary directory and have s6 start (and supervise) them.
3. **stage 3**: This is the shutdown stage. When the container is supposed to exit, it will:
    1. Send a TERM signal to all legacy longrun services and, if required, wait for them to exit.
    2. Bring down user s6-rc services in an orderly fashion.
    3. Run any finalization scripts contained in `/etc/cont-finish.d`.
    4. Send all remaining processes a `TERM` signal. There should not be any remaining processes anyway.
    5. Sleep for a small grace time, to allow stray processes to exit cleanly.
    6. Send all processes a `KILL` signal. Then the container exits.

## Installation

s6-overlay comes as a set of tarballs that you can extract onto your image.
The tarballs you need are a function of the image you use; most people will
need the first two, and the other ones are extras you can use at your
convenience.

1. `s6-overlay-noarch.tar.xz`: this tarball contains the scripts
implementing the overlay. We call it "noarch" because it is architecture-
independent: it only contains scripts and other text files. Everyone who
wants to run s6-overlay needs to extract this tarball.
2. `s6-overlay-x86_64.tar.xz`: replace `x86_64` with your
system's architecture. This tarball contains all the necessary binaries
from the s6 ecosystem, all linked statically and out of the way of
your image's binaries. Unless you know for sure that your image already
comes with all the packages providing the binaries used in the overlay,
you need to extract this tarball.
3. `s6-overlay-symlinks-noarch.tar.xz`: this tarball contains
symlinks to the s6-overlay scripts so they are accessible via `/usr/bin`.
It is normally not needed, all the scripts are accessible via the PATH
environment variable, but if you have old user scripts containing
shebangs such as `#!/usr/bin/with-contenv`, installing these symlinks
will make them work.
4. `s6-overlay-symlinks-arch.tar.xz`: this tarball contains
symlinks to the binaries from the s6 ecosystem provided by the second
tarball, to make them accessible via `/usr/bin`. It is normally not
needed, but if you have old user scripts containing shebangs such as
`#!/usr/bin/execlineb`, installing these symlinks will make them work.
5. `syslogd-overlay-noarch.tar.xz`: this tarball contains
definitions for a `syslogd` service. If you are running daemons that
cannot log to stderr to take advantage of the s6 logging infrastructure,
but hardcode the use of the old `syslog()` mechanism, you can extract
this tarball, and your container will run a lightweight emulation of a
`syslogd` daemon, so your syslog logs will be caught and stored to disk.

To install those tarballs, add lines to your Dockerfile that correspond
to the functionality you want to install. For instance, most people would
use the following:
```
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz
```

Make sure to preserve file permissions when extracting (i.e. to use the
`-p` option to `tar`.)

## Usage

The project is distributed as a set of standard .tar.xz files, which you extract at the root of your image.
(You need the xz-utils package for `tar` to understand `.tar.xz` files; it is available
in every distribution, but not always in the default container images, so you may need
to `apt install xz-utils` or `apk add xz-utils`, or equivalent, before you can
expand the archives.)

Afterwards, set your `ENTRYPOINT` to `/init`.

Right now, we recommend using Docker's `ADD` directive instead of running `wget` or `curl`
in a `RUN` directive - Docker is able to handle the https URL when you use `ADD`, whereas
your base image might not be able to use https, or might not even have `wget` or `curl`
installed at all.

From there, you have a couple of options:

* If you want the container to exit when your program exits: run the program as your image's `CMD`.
* If you want the container to run until told to exit, and your program to be supervised by s6:
write a service script for your program.

### Using `CMD`

Using `CMD` is a convenient way to take advantage of the overlay. Your `CMD` can be given at
build time in the Dockerfile, or at run time on the command line, either way is fine. It will
be run as a normal process in the environment set up by s6; when it fails or exits, the
container will shut down cleanly and exit. You can run interactive programs in this manner:
only the CMD will receive your interactive command, the support processes will be unimpacted.

For example:

```
FROM busybox
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-noarch.tar.xz
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
RUN tar -C / -Jxpf /tmp/s6-overlay-x86_64.tar.xz
ENTRYPOINT ["/init"]
```

```
docker-host $ docker build -t s6demo .
docker-host $ docker run -ti s6demo /bin/sh
/package/admin/s6-overlay/libexec/preinit: notice: /var/run is not a symlink to /run, fixing it
s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
/ # ps
PID   USER     TIME  COMMAND
    1 root      0:00 /package/admin/s6/command/s6-svscan -d4 -- /run/service
   17 root      0:00 {rc.init} /bin/sh -e /run/s6/basedir/scripts/rc.init top /bin/sh
   18 root      0:00 s6-supervise s6-linux-init-shutdownd
   20 root      0:00 /package/admin/s6-linux-init/command/s6-linux-init-shutdownd -c /run/s6/basedir -g 3000 -C -B
   24 root      0:00 s6-supervise s6rc-fdholder
   25 root      0:00 s6-supervise s6rc-oneshot-runner
   31 root      0:00 /package/admin/s6/command/s6-ipcserverd -1 -- /package/admin/s6/command/s6-ipcserver-access -v0 -E -l0 -i data/rules -- /packa
   58 root      0:00 /bin/sh
   66 root      0:00 ps
/ # exit
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service s6rc-oneshot-runner: stopping
s6-rc: info: service s6rc-oneshot-runner successfully stopped
docker-host $
```

### Writing a service script

The other way to use a container with s6-overlay is to make your
services supervised. You can supervise any number of services;
usually they're just support services for the main daemon you run as
a CMD, but if that's what you want, nothing prevents you from having
an empty CMD and running your main daemon as a supervised service as
well. In that case, the daemon will be restarted by s6 whenever it
exits; the container will only stop when you tell it to do so, either
via a `docker stop` command, or from inside the container with the
`/run/s6/basedir/bin/halt` command.

There are two ways of making a supervised service. The old way, which
is still supported, is to make a "pure s6" service directory. Create a
directory with the name of your service in `/etc/services.d` and put an executable `run`
file into it; this is the file in which you'll put your long-lived process execution.
For details of supervision of service directories, and how you can
configure how s6 handles your daemon, you can take a look at the
[servicedir](https://skarnet.org/software/s6/servicedir.html) documentation.
A simple example would look like this:

`/etc/services.d/myapp/run`:
```
#!/command/execlineb -P
nginx -g "daemon off;"
```

The new way is to make an [s6-rc](https://skarnet.org/software/s6-rc/)
*source definition directory* in the `/etc/s6-overlay/s6-rc.d` directory,
and add the name of that directory to the `user` bundle, i.e. create an
empty file with the same name in the `/etc/s6-overlay/s6-rc.d/user/contents.d`
directory. The format of a *source definition directory* is described in
[this page](https://skarnet.org/software/s6-rc/s6-rc-compile.html). Note that
you can define *longruns*, i.e. daemons that will get supervised by s6 just
like with the `/etc/services.d` method, but also *oneshots*, i.e. programs that
will run once and exit. Your main service is probably a *longrun*, not a
*oneshot*: you probably need a daemon to stick around.

The advantage of this new format is that it allows you to define dependencies
between services: if *B* depends on *A*, then *A* will start first, then *B* will
start when *A* is ready, and when the container is told to exit, *B* will stop
first, then *A*. If you have a complex architecture where various processes
depends on one another, or simply where you have to mix *oneshots* and *longruns*
in a precise order, this may be for you.

The example above could be rewritten this way:

`/etc/s6-overlay/s6-rc.d/myapp/type`:
```
longrun
```

`/etc/s6-overlay/s6-rc.d/myapp/run`:
```
#!/command/execlineb -P
nginx -g "daemon off;"
```

`/etc/s6-overlay/s6-rc.d/user/contents.d/myapp`: empty file.
(This adds `myapp` to the set of services that s6-rc will start at
container boot.)

`/etc/s6-overlay/s6-rc.d/myapp/dependencies.d/base`: empty file.
(This tells s6-rc to only start `myapp` when all the base services
are ready: it prevents race conditions.)

We encourage you to switch to the new format, but if you don't need its
benefits, you can stick with regular service directories in `/etc/services.d`,
it will work just as well.

### Setting the exit code of the container to the exit code of your main service

If you run your main service as a CMD, you have nothing to do: when your CMD
exits, or when you run `docker stop`, the container will naturally exit with the
same exit code as your service. (Be aware, however, that in the `docker stop`
case, your service will get a SIGTERM, in which case the exit code will entirely
depend on how your service handles it - it could trap it and exit 0, trap it and
exit something else, or not trap it and let the shell exit its own code for it -
normally 130.)

If you run your main service as a supervised service, however, things are
different, and you need to tell the container what code to exit with when you
send it a `docker stop` command. To do that, you need to write a `finish` script:

- If your service is a legacy service in `/etc/services.d`, you need an
executable `/etc/services.d/myapp/finish` script.
- If your service is an s6-rc one, you need a
`/etc/s6-overlay/s6-rc.d/myapp/finish` file containing your script (the
file may or may not be executable).

This `finish` script will be run when your service exits, and will take
two arguments:

- The first argument will be the exit code of your service, or 256 if
your service was killed by an uncaught signal.
- The second argument is only meaningful if your service was killed by
an uncaught signal, and contains the number of said signal.

In the `finish` script, you need to write the container exit code you
want to the `/run/s6-linux-init-container-results/exitcode` file - and
that's it.

For instance, the `finish` script for the `myapp` service above could
be something like this:
```sh
#!/bin/sh

if test "$1" -eq 256 ; then
  e=$((128 + $2))
else
  e="$1"
fi

echo "$e" > /run/s6-linux-init-container-results/exitcode
```
When you send a `docker stop` command to your container, the `myapp`
service will be killed and this script will be run; it will write
either `myapp`'s exit code (if `myapp` catches the TERM signal) or
130 (if `myapp` does not catch the TERM signal) to the special
`/run/s6-linux-init-container-results/exitcode` file, which will
be read by s6-overlay at the end of the container shutdown procedure,
and your container will exit with that value.

### Fixing ownership and permissions

This section describes a functionality from the versions of s6-overlay
that are **anterior to** v3. fix-attrs is still supported in v3,
but is **deprecated**, for several reasons: one of them is that it's
generally not good policy to change ownership dynamically when it can be
done statically. Another reason is that it doesn't work with USER containers.
Instead of fix-attrs, we now recommend you to take care of ownership and
permissions on host mounts *offline, before running the container*. This
should be done in your Dockerfile, when you have all the needed information.

That said, here is what we wrote for previous versions and that is still
applicable today (but please stop depending on it):

Sometimes it's interesting to fix ownership & permissions before proceeding because,
for example, you have mounted/mapped a host folder inside your container. Our overlay
provides a way to tackle this issue using files in `/etc/fix-attrs.d`.
This is the pattern format followed by fix-attrs files:

```
path recurse account fmode dmode
```
* `path`: File or dir path.
* `recurse`: (Set to `true` or `false`) If a folder is found, recurse through all containing files & folders in it.
* `account`: Target account. It's possible to default to fallback `uid:gid` if the account isn't found. For example, `nobody,32768:32768` would try to use the `nobody` account first, then fallback to `uid 32768` instead.
If, for instance, `daemon` account is `UID=2` and `GID=2`, these are the possible values for `account` field:
  * `daemon:                UID=2     GID=2`
  * `daemon,3:4:            UID=2     GID=2`
  * `2:2,3:4:               UID=2     GID=2`
  * `daemon:11111,3:4:      UID=2     GID=11111`
  * `11111:daemon,3:4:      UID=11111 GID=2`
  * `daemon:daemon,3:4:     UID=2     GID=2`
  * `daemon:unexisting,3:4: UID=2     GID=4`
  * `unexisting:daemon,3:4: UID=3     GID=2`
  * `11111:11111,3:4:       UID=11111 GID=11111`
* `fmode`: Target file mode. For example, `0644`.
* `dmode`: Target dir/folder mode. For example, `0755`.

Here you have some working examples:

`/etc/fix-attrs.d/01-mysql-data-dir`:
```
/var/lib/mysql true mysql 0600 0700
```
`/etc/fix-attrs.d/02-mysql-log-dirs`:
```
/var/log/mysql-error-logs true nobody,32768:32768 0644 2700
/var/log/mysql-general-logs true nobody,32768:32768 0644 2700
/var/log/mysql-slow-query-logs true nobody,32768:32768 0644 2700
```

### Executing initialization and finalization tasks

Here is the old way of doing it:

After fixing attributes (through `/etc/fix-attrs.d/`) and before starting
user provided services (through s6-rc or `/etc/services.d`) our overlay will
execute all the scripts found in `/etc/cont-init.d`, for example:

[`/etc/cont-init.d/02-confd-onetime`](https://github.com/just-containers/nginx-loadbalancer/blob/master/rootfs/etc/cont-init.d/02-confd-onetime):
```
#!/command/execlineb -P

with-contenv
s6-envuidgid nginx
multisubstitute
{
  import -u -D0 UID
  import -u -D0 GID
  import -u CONFD_PREFIX
  define CONFD_CHECK_CMD "/usr/sbin/nginx -t -c {{ .src }}"
}
confd --onetime --prefix="${CONFD_PREFIX}" --tmpl-uid="${UID}" --tmpl-gid="${GID}" --tmpl-src="/etc/nginx/nginx.conf.tmpl" --tmpl-dest="/etc/nginx/nginx.conf" --tmpl-check-cmd="${CONFD_CHECK_CMD}" etcd
```

This way is still supported. However, there is now a more generic and
efficient way to do it: writing your oneshot initialization and finalization
tasks as s6-rc services, by adding service definition directories in
`/etc/s6-overlay/s6-rc.d`, making them part of the `user` bundle (so they
are actually started when the container boots), and making them depend on
the `base` bundle (so they are only started after `base`).

All the information on s6-rc can be found [here](https://skarnet.org/software/s6-rc/).

When the container is started, the operations are performed in this order:

- (deprecated) Attribute fixing is performed according to files in `/etc/fix-attrs.d`.
- (legacy) One-shot initialization scripts in `/etc/cont-init.d` are run sequentially.
- Services in the `user` bundle are started by s6-rc, in an order defined by
dependencies. Services can be oneshots (initialization
tasks) or longruns (daemons that will run throughout the container's lifetime). If
the services depend on `base`, they are guaranteed to start at this point and not
earlier; if they do not, they might have been started earlier, which may cause
race conditions - so it's recommended to always make them depend on `base`.
- (legacy) Longrun services in `/etc/services.d` are started.
- Services in the `user2` bundle with the correct dependency are started.
(Most people don't need to use this; if you are not sure, stick to the `user` bundle.)

When the container is stopped, either because the admin sent a stop command or
because the CMD exited, the operations are performed in the reverse order:

- Services in the `user2` bundle with the correct dependency are stopped.
- (legacy) Longrun services in `/etc/services.d` are stopped.
- All s6-rc services are stopped, in an order defined by dependencies. For
oneshots, that means that the `down` script in the source definition directory
is executed; that's how s6-rc can perform finalization tasks.
- (legacy) One shot finalization scripts in `/etc/cont-finish.d` are run sequentially.

The point of the `user2` bundle is to allow user services declared in it to
start *after* the `/etc/services.d` ones; but in order to do so, every service
in `user2` needs to declare a dependency to `legacy-services`. In other words,
for a service `foobar` to start late, you need to:
- Define it in `/etc/s6-overlay/s6-rc.d/foobar` like any other s6-rc service.
- Add an `/etc/s6-overlay/s6-rc.d/foobar/dependencies.d/legacy-services` file
- Add an `/etc/s6-overlay/s6-rc.d/user2/contents.d/foobar` file.

That will ensure that `foobar` will start _after_ everything in `/etc/services.d`.

### Writing an optional finish script

By default, services created in `/etc/services.d` will automatically restart.
If a service should bring the container down, you should probably run it as
a CMD instead; but if you'd rather run it as a supervised service, then you'll
need to write a `finish` script, which will be run when the service is down; to
make the container stop, the `/run/s6/basedir/bin/halt` command must be invoked.
Here's an example finish script:

`/etc/services.d/myapp/finish`:
```
#!/command/execlineb -S0

foreground { redirfd -w 1 /run/s6-linux-init-container-results/exitcode echo 0 }
/run/s6/basedir/bin/halt
```

The first line of the script writes `0` to the `/run/s6-linux-init-container-results/exitcode` file.
The second line stops the container. When you stop the container via the `/run/s6/basedir/bin/halt`
command run from inside the container, `/run/s6-linux-init-container-results/exitcode` is read and
its contents are used as the exit code for the `docker run` command that launched the container.
If the file doesn't exist, or if the container is stopped with `docker stop` or another reason,
that exit code defaults to 0.

It is possible to do more advanced operations in a finish script. For example, here's a script
from that only brings down the service when it exits nonzero:

`/etc/services.d/myapp/finish`:
```
#!/command/execlineb -S1
if { eltest ${1} -ne 0 -a ${1} -ne 256 }
/run/s6/basedir/bin/halt
```

Note that in general, finish scripts should only be used for local cleanups
after a daemon dies. If a service is so important that the container needs
to stop when it dies, we really recommend running it as the CMD.

### Logging

Every service can have its dedicated logger. A logger is a s6 service that
automatically reads from the *stdout* of your service, and logs the data
to an automatically rotated file in the place you want. Note that daemons
usually log to stderr, not stdout, so you should probably start your service's
run script with `exec 2>&1` in shell, or with `fdmove -c 2 1` in execline, in
order to catch *stderr*.

s6-overlay provides a utility called `logutil-service` which is a wrapper over
the [`s6-log`](https://skarnet.org/software/s6/s6-log.html) program.
This helper does the following:
- read how s6-log should proceed reading the logging script contained in `S6_LOGGING_SCRIPT`
- drop privileges to the `nobody` user (defaulting to `65534:65534` if it doesn't exist)
- clean all the environments variables
- execute into s6-log.

s6-log will then run forever, reading data from your service and writing it to
the directory you specified to `logutil-service`.

Please note:
- Since the privileges are dropped automatically, there is no need to switch users with `s6-setuidgid`
- You should ensure the log folder either:
  - exists, and is writable by the `nobody` user
  - does not exist, but the parent folder is writable by the `nobody` user.

You can create log folders in `cont-init.d` scripts, or as s6-rc oneshots.
Here is an example of a logged service `myapp` implemented the old way:

`/etc/cont-init.d/myapp-log-prepare`:
```sh
#!/bin/sh -e
mkdir -p /var/log/myapp
chown nobody:nogroup /var/log/myapp
chmod 02755 /var/log/myapp
```

`/etc/services.d/myapp/run`:
```sh
#!/bin/sh
exec 2>&1
exec mydaemon-in-the-foreground-and-logging-to-stderr
```

`/etc/services.d/myapp/log/run`:
```sh
#!/bin/sh
exec logutil-service /var/log/myapp
```

And here is the same service, myapp, implemented in s6-rc.

`/etc/s6-overlay/s6-rc.d/myapp-log-prepare/dependencies.d/base`: empty file

`/etc/s6-overlay/s6-rc.d/myapp-log-prepare/type`:
```
oneshot
```

`/etc/s6-overlay/s6-rc.d/myapp-log-prepare/up`:
```
if { mkdir -p /var/log/myapp }
if { chown nobody:nogroup /var/log/myapp }
chmod 02755 /var/log/myapp
```

<details><summary>(Click here for an explanation of the weird syntax
or if you don't understand why your `up` file isn't working.)</summary>
<p>

(Beginning of the detailed section.)

So, the `up` and `down` files are special: they're not shell scripts, but
single command lines interpreted by [execlineb](https://skarnet.org/software/execline/execlineb.html).
You should not have to worry about execline; you should only remember that
an `up` file contains a single command line. So if you need a script with
several instructions, here's how to do it:

- Write your script in the language of your choice, in a location of your choice
- Make it executable
- Call that script in the `up` file.

Here is how you would normally proceed to write the `up` file for
`myapp-log-prepare`:

`/etc/s6-overlay/s6-rc.d/myapp-log-prepare/up`:
```
/etc/s6-overlay/scripts/myapp-log-prepare
```

`/etc/s6-overlay/scripts/myapp-log-prepare`: (needs to be executable)
```sh
#!/bin/sh -e
mkdir -p /var/log/myapp
chown nobody:nogroup /var/log/myapp
chmod 02755 /var/log/myapp
```

The location of the actual script is arbitrary, it just needs to match
what you're writing in the `up` file.

But here, it just so happens that the script is simple enough that it can
fit entirely in the `up` file without making it too complex or too
difficult to understand. So, we chose to include it as an example to
show that there's more that you can do with `up` files, if you are
so inclined. You can read the full documentation for the execline
language [here](https://skarnet.org/software/execline/).

(End of the detailed section, click the triangle above again to collapse.)
</p>
</details>

`/etc/s6-overlay/s6-rc.d/myapp/dependencies.d/base`: empty file

`/etc/s6-overlay/s6-rc.d/myapp-log/dependencies.d/myapp-log-prepare`: empty file

`/etc/s6-overlay/s6-rc.d/myapp/type`:
```
longrun
```

`/etc/s6-overlay/s6-rc.d/myapp/run`:
```sh
#!/bin/sh
exec 2>&1
exec mydaemon-in-the-foreground-and-logging-to-stderr
```

`/etc/s6-overlay/s6-rc.d/myapp/producer-for`:
```
myapp-log
```

`/etc/s6-overlay/s6-rc.d/myapp-log/type`:
```
longrun
```

`/etc/s6-overlay/s6-rc.d/myapp-log/run`:
```sh
#!/bin/sh
exec logutil-service /var/log/myapp
```

`/etc/s6-overlay/s6-rc.d/myapp-log/consumer-for`:
```
myapp
```

`/etc/s6-overlay/s6-rc.d/myapp-log/pipeline-name`:
```
myapp-pipeline
```

`/etc/s6-overlay/s6-rc.d/user/contents.d/myapp-pipeline`: empty file

That's a lot of files! A summary of what it all means is:
- myapp-log-prepare is a oneshot, preparing the logging directory.
It is a dependency of myapp-log, so it will be started *before* myapp-log.
- myapp is a producer for myapp-log and myapp-log is a consumer for myapp,
so what myapp writes to its stdout will go to myapp-log's stdin. Both
are longruns, i.e. daemons that will be supervised by s6.
- The `myapp | myapp-log` pipeline is given a name, `myapp-pipeline`, and
this name is declared as a part of the `user` bundle, so it will be started
when the container starts.
- `myapp-log-prepare`, `myapp-log` and `myapp` all depend on the `base`
bundle, which means they will only be started when the system is actually
ready to start them.

It really accomplishes the same things as the `/etc/cont-init.d` plus
`/etc/services.d` method, but it's a lot cleaner underneath, and can handle
much more complex dependency graphs, so whenever you get the opportunity,
we recommend you familiarize yourself with the [s6-rc](https://skarnet.org/software/s6-rc/)
way of declaring your services and your loggers. The full syntax of a
service definition directory, including declaring whether your service
is a longrun or a oneshot, declaring pipelines, adding service-specific
timeouts if you need them, etc., can be found
[here](https://skarnet.org/software/s6-rc/s6-rc-compile.html#source).

### Dropping privileges

When it comes to executing a service, no matter whether it's a service or a logger,
a good practice is to drop privileges before executing it.
`s6` already includes utilities to do exactly these kind of things:

In `execline`:

```
#!/command/execlineb -P
s6-setuidgid daemon
myservice
```

In `sh`:

```sh
#!/bin/sh
exec s6-setuidgid daemon myservice
```

If you want to know more about these utilities, please take a look at:
[`s6-setuidgid`](http://skarnet.org/software/s6/s6-setuidgid.html),
[`s6-envuidgid`](http://skarnet.org/software/s6/s6-envuidgid.html), and
[`s6-applyuidgid`](http://skarnet.org/software/s6/s6-applyuidgid.html).

### Container environment

If you want your custom script to have container environments available:
you can use the `with-contenv` helper, which will push all of those into your
execution environment, for example:

`/etc/cont-init.d/01-contenv-example`:
```sh
#!/command/with-contenv sh
env
```

This script will output the contents of your container environment.

### Read-Only Root Filesystem

Recent versions of Docker allow running containers with a read-only root filesystem.
If your container is in such a case, you should set `S6_READ_ONLY_ROOT=1` to inform
s6-overlay that it should not attempt to write to certain areas - instead, it will
perform copies into a tmpfs mounted on `/run`.

Note that s6-overlay assumes that:
- `/run` exists and is writable. If it is not, it will attempt to mount a tmpfs there.
- `/var/run` is a symbolic link to `/run`, for compatibility with previous versions. If it is not, it will make it so.

In general your default docker settings should already provide a suitable tmpfs in `/run`.

### Customizing s6-overlay behaviour

It is possible somehow to tweak s6-overlay's behaviour by providing an already predefined set of environment variables to the execution context:

* `PATH` (default = `/command:/usr/bin:/bin`):
this is the default PATH that all the services in the container,
including the CMD, will have. Set this variable if you have a lot
of services that depend on binaries stored in another directory, e.g.
`/usr/sbin`. Note that `/command`, `/usr/bin` and `/bin` will always
be added to that path if they're not already in the one you provide.
* `S6_KEEP_ENV` (default = 0): if set, then environment is not reset and whole supervision tree sees original set of env vars. It switches `with-contenv` into a nop.
* `S6_LOGGING` (default = 0):
  * **`0`**: Outputs everything to stdout/stderr.
  * **`1`**: Uses an internal `catch-all` logger and persists everything on it, it is located in `/var/log/s6-uncaught-logs`. Anything run as a `CMD` is still output to stdout/stderr.
  * **`2`**: Uses an internal `catch-all` logger and persists everything on it, including the output of `CMD`. Absolutely nothing is written to stdout/stderr.
* `S6_CATCHALL_USER` (default = root): if set, and if `S6_LOGGING` is 1 or 2,
then the catch-all logger is run as this user, which must be defined in your
image's `/etc/passwd`. Every bit of privilege separation helps a little with security.
* `S6_BEHAVIOUR_IF_STAGE2_FAILS` (default = 0): determines what the container should do
if one of the service scripts fails. This includes:
  * if anything fails in `fix-attrs`
  * if any old-style `/etc/cont-init.d` or new-style [s6-rc](https://skarnet.org/software/s6-rc/) oneshot fails
  * if any old-style `/etc/services.d` or new-style [s6-rc](https://skarnet.org/software/s6-rc/) longrun is marked
as expecting readiness notification, and fails to become *ready* in the allotted time (see
`S6_CMD_WAIT_FOR_SERVICES_MAXTIME` below). The valid values for `S6_BEHAVIOUR_IF_STAGE2_FAILS`
are the following:
  * **`0`**: Continue silently even if a script has failed.
  * **`1`**: Continue but warn with an annoying error message.
  * **`2`**: Stop the container.
* `S6_KILL_FINISH_MAXTIME` (default = 5000): How long (in milliseconds) the system should
wait, at shutdown time, for a script in `/etc/cont-finish.d` to finish naturally. After this
duration, the script will be sent a SIGKILL. Bear in mind that scripts in `/etc/cont.finish.d`
are run sequentially, and the shutdown sequence will potentially wait for `S6_KILL_FINISH_MAXTIME`
milliseconds for *each* script.
* `S6_SERVICES_READYTIME` (default = 50): With services declared in `/etc/services.d`, there is
an unavoidable race condition between the moment when services are started and the moment when
they can be tested for readiness. To avoid that race, we sleep a little time, by default 50
milliseconds, before testing for readiness. If your machine is slow or very busy, you may
get errors looking like `s6-svwait: fatal: unable to s6_svstatus_read: No such file or directory`.
In that case, you should increase the sleeping time, by declaring it (in milliseconds) in the
`S6_SERVICES_READYTIME` variable. Note that it only concerns `/etc/services.d`; s6-rc is immune
to the race condition.
* `S6_SERVICES_GRACETIME` (default = 3000): How long (in milliseconds) `s6` should wait,
at shutdown time, for services declared in `/etc/services.d` to die before proceeding
with the rest of the shutdown.
* `S6_KILL_GRACETIME` (default = 3000): How long (in milliseconds) `s6` should wait, at the end of
the shutdown procedure when all the processes have received a TERM signal, for them to die
before sending a `KILL` signal to make *sure* they're dead.
* `S6_LOGGING_SCRIPT` (default = "n20 s1000000 T"): This env decides what to log and how, by default every line will prepend with ISO8601, rotated when the current logging file reaches 1mb and archived, at most, with 20 files.
* `S6_CMD_ARG0` (default = not set): Value of this env var will be prepended to any `CMD` args passed by docker. Use it if you are migrating an existing image to s6-overlay and want to make it a drop-in replacement: setting this variable to the value of a previously used ENTRYPOINT will help you transition.
* `S6_CMD_USE_TERMINAL` (default = 0): Set this value to **1** if you have a CMD that needs a terminal for its output
(typically when you're running your container with `docker run -it`), and you have set `S6_LOGGING` to a nonzero value.
This setting will make your CMD actually output to your terminal; the drawback is that its output will not be logged.
By default (when this variable is **0** or not set), the stdout and stderr of your CMD are logged when `S6_LOGGING` is nonzero,
which means they go to a pipe even if you're running it in an interactive terminal.
* `S6_FIX_ATTRS_HIDDEN` (default = 0): Controls how `fix-attrs.d` scripts process files and directories.
  * **`0`**: Hidden files and directories are excluded.
  * **`1`**: All files and directories are processed.
* `S6_CMD_WAIT_FOR_SERVICES` (default = 0): By default when the container starts,
services in `/etc/services.d` will be started and execution will proceed to
starting the `user2` bundle and the CMD, if any of these is defined. If
`S6_CMD_WAIT_FOR_SERVICES` is nonzero, however, the container starting sequence
will wait until the services in `/etc/services.d` are *ready* before proceeding
with the rest of the sequence. Note that this is only significant if the services in `/etc/services.d`
[notify their readiness](https://skarnet.org/software/s6/notifywhenup.html) to s6.
* `S6_CMD_WAIT_FOR_SERVICES_MAXTIME` (default = 5000): The maximum time (in milliseconds) the services could take to bring up before proceding to CMD executing.
Note that this value also includes the time setting up legacy container initialization (`/etc/cont-init.d`) and services (`/etc/services.d`),
and that it is taken into account even if you are not running a CMD. In other words: no matter whether you're running a CMD or not,
if you have scripts in `/etc/cont-init.d` that take a long time to run, you should set this variable to either 0, or a value high
enough so that your scripts have time to finish without s6-overlay interrupting them and diagnosing an error.
* `S6_READ_ONLY_ROOT` (default = 0): When running in a container whose root filesystem is read-only, set this env to **1** to inform init stage 2 that it should copy user-provided initialization scripts from `/etc` to `/run/s6/etc` before it attempts to change permissions, etc. See [Read-Only Root Filesystem](#read-only-root-filesystem) for more information.
* `S6_SYNC_DISKS` (default = 0): Set this env to **1** to inform init stage 3 that it should attempt to sync filesystems before stopping the container. Note: this will likely sync all filesystems on the host.
* `S6_STAGE2_HOOK` (default = none): If this variable exists, its contents
will be interpreted as a shell excerpt that will be run in the early stage 2,
before services are started. This can be used, for instance, to dynamically
patch the service database at run-time right before it is compiled and run.
The wrong value can prevent your container from running or endanger your
security, so only use this if you know exactly what you are doing. When in
doubt, leave this variable undefined.
* `S6_VERBOSITY` (default = 2): controls the verbosity of s6-rc, and potentially
other tools, at container start and stop time. The default, 2, is normally verbose:
it will list the service start and stop operations. You can make the container quieter
by decreasing this number: 1 will only print warnings and errors, and 0 will only
print errors. You can also make the container _more_ verbose, i.e. print tracing and
debug information, by increasing this number up to 5, but the output will quickly
become _very_ noisy, and most people shouldn't need this.
* `S6_CMD_RECEIVE_SIGNALS` (default = 0): decides whether signals sent to the
container should be sent to the container's pid 1 or to the CMD. By default, when
you perform for instance a `docker stop`, a TERM signal will be sent to the
container's pid 1, which will trigger the full container shutdown sequence - but
if a CMD is present, it will be among the last processes to be killed, only when
everything else is down and the container is about to exit. If this variable is
1 or more, signals are diverted from pid 1 to the CMD, which means that `docker stop`
will send a SIGTERM to the CMD instead, and the container will only trigger its shutdown
procedure when the CMD is dead. Note that only SIGTERM, SIGQUIT, SIGINT, SIGUSR1,
SIGUSR2, SIGPWR and SIGWINCH are diverted; other signals either are ignored or
cannot be diverted and are necessarily handled by pid 1. Please be aware that using
this option may prevent interactive CMDs from working at all - in other words, if
you're running an interactive CMD in a terminal, don't set this variable; but that
should be fine since in this case you already have interactive ways of stopping your CMD.

### syslog

If software running in your container requires syslog, extract the
`syslogd-overlay-noarch.tar.xz` tarball:
that will give you a small syslogd emulation. Logs will be found
under various subdirectories of `/var/log/syslogd`, for instance
messages will be found in the `/var/log/syslogd/messages/` directory,
the latest logs being available in the `/var/log/syslogd/messages/current` file.
Logging directories are used rather than files so that logs can be
automatically rotated without race conditions (that is a feature of
[s6-log](https://skarnet.org/software/s6/s6-log.html)).

It is recommended to add `syslog` and `sysllog` users to your image, for
privilege separation; the syslogd emulation processes will run as these users
if they exist. Otherwise they will default to `32760:32760` and `32761:32761`,
numeric uids/gids that may already exist on your system.

## Performance

- The noarch and symlinks tarballs are all tiny. The biggest tarball is the
one that contains the binaries; it's around 650 kB.
- Uncompressed on a tmpfs, the overlay scripts use about 120 kB, and the
binaries for x86_64 use about 5.7 MB.
- We haven't yet measured the time it takes for the container to be up and running
once you run `docker run`, but you will notice it's fast. Faster than previous
versions of s6-overlay, with fewer delays. And if you convert your `/etc/cont-init.d`
scripts to the s6-rc format, they will be able to run in parallel, so you will
gain even more performance. If you have benchmarks, please send them to us!

## Verifying Downloads

The s6-overlay releases have a checksum files you can use to verify
the download using SHA256:

```sh
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz /tmp
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-noarch.tar.xz.sha256 /tmp
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz /tmp
ADD https://github.com/just-containers/s6-overlay/releases/download/v${S6_OVERLAY_VERSION}/s6-overlay-x86_64.tar.xz.sha256 /tmp
RUN cd /tmp && sha256sum -c *.sha256
```

## Notes

### `USER` directive

As of version <IP_ADDRESS>, s6-overlay has limited support for running as a user other than `root`:

* Tools like `fix-attrs` and `logutil-service` are unlikely to work (they rely
  on being able to change UIDs).
* The syslogd emulation will not work.

Generally speaking, if you're running a simple container with a main application and
one or two support services, you may benefit from the `USER` directive if that is
your preferred way of running containers. However, if you're running more than a few
services, or daemons that expect a real system with complete Unix infrastructure,
then USER is probably not a good idea and you would benefit more from using
privilege separation between services in your container.

## Releases

Over on the releases tab, we have a number of tarballs:

* `s6-overlay-noarch.tar.xz`: the s6-overlay scripts.
* `s6-overlay-${arch}.tar.xz`: the binaries for platform *${arch}*.
They are statically compiled and will work with any Linux distribution.
* `s6-overlay-symlinks-noarch.tar.xz`: `/usr/bin` symlinks to the s6-overlay scripts. Totally optional.
* `s6-overlay-symlinks-arch.tar.xz`: `/usr/bin` symlinks to the skaware binaries. Totally optional.
* `syslogd-overlay-noarch.tar.xz`: the syslogd emulation. Totally optional.
* `s6-overlay-${version}.tar.xz`: the s6-overlay source. Download it if you want to build s6-overlay yourself.

We have binaries for at least x86_64, aarch64, arm32, i486, i686, riscv64, and s390x.
The full list of supported arches can be found in [conf/toolchains](https://github.com/just-containers/s6-overlay/blob/master/conf/toolchains).

### Which architecture to use depending on your TARGETARCH

The `${arch}` part in the `s6-overlay-${arch}.tar.xz` tarball uses
the naming conventions of gcc, which are not the ones that Docker
uses. (Everyone does something different in this field depending on
their needs, and no solution is better than any other, but the Docker
one is *worse* than others because its naming is inconsistent. The gcc
convention is better for us because it simplifies our builds greatly and
makes them more maintainable.)

The following table should help you find the right tarball for you
if you're using the TARGETARCH value provided by Docker:

| ${TARGETARCH} | ${arch} | Notes                 |
|:--------------|:--------|:----------------------|
| amd64         | x86_64  |                       |
| arm64         | aarch64 |                       |
| arm/v7        | arm     | armv7 with soft-float |
| arm/v6        | armhf   | Raspberry Pi 1        |
| 386           | i686    | i486 for very old hw  |
| riscv64       | riscv64 |                       |
| s390x         | s390x   |                       |

If you need another architecture, ask us and we'll try to make a toolchain
for it. In particular, we know that armv7 is a mess and needs a flurry of
options depending on your precise target (and this is one of the reasons why
the Docker naming system isn't good, although arguably the gcc naming system
isn't much better on that aspect).

## Contributing

Any way you want! Open issues, open PRs, we welcome all contributors!

## Building the overlay yourself

- Download the [s6-overlay source].
- Check the [conf/defaults.mk](https://github.com/just-containers/s6-overlay/blob/master/conf/defaults.mk)
file for variables you may want to change. Do not modify the file itself.
- Call `make` followed by your variable assignments. Example: `make ARCH=riscv64-linux-musl`
to build the overlay for RISCV64.
- The tarballs will be in the `output` subdirectory, unless you changed the `OUTPUT` variable.

## Upgrade Notes

Please see [CHANGELOG](./CHANGELOG.md).

license: ISC

gha_language: Shell

gha_license_id: NOASSERTION


text:
---
layout: post
title: "Understanding the Game Loop of Cocos2d-x"
date: 2019-01-24 17:21:10 +0800
category: Code-Review
tags: cocos2dx game-engine
---

This post is a code review of the game loop of [Cocos2d-x (v3.10)](https://github.com/cocos2d/cocos2d-x/tree/v3). The game loop is the heart of a game. It keeps the game running.

In the game loop of Cocos2d-x, there are two phases: 1. Drawing the current scene; 2. Cleaning up objects in the auto-release pool. In the `DisplayLinkDirector::mainLoop()`:

```c++
drawScene();
PoolManager::getInstance()->getCurrentPool()->clear();
```

What jobs done in the [`drawScene`](https://github.com/cocos2d/cocos2d-x/blob/e71ef8218cb58a66ec07cf9cc5ac80ac4e695ebd/cocos/base/CCDirector.cpp#L259) method?

- Handle input events.

    ```c++
    if (_openGLView)
    {
        _openGLView->pollEvents();
    }
    ```

    However, the `pollEvents` of `GLView` is an empty implementation. I have find only one actual implementation which calls the [`glfwPollEvents`](https://www.glfw.org/docs/latest/group__window.html#ga37bd57223967b4211d60ca1a0bf3c832) method in the `CCGLViewImpl-desktop` file.

- Tick the scheduler.

    ```c++
    if (! _paused)
    {
        _eventDispatcher->dispatchEvent(_eventBeforeUpdate);
        _scheduler->update(_deltaTime);
        _eventDispatcher->dispatchEvent(_eventAfterUpdate);
    }
    ```

- Clear GL buffers and all [FBOs](https://www.khronos.org/opengl/wiki/Framebuffer_Object).

    ```c++
    _renderer->clear();
    experimental::FrameBuffer::clearAllFBOs();
    ```

- Set the next scene, i.e. if the `_nextScene` is not null, assign it to the `_runningScene`.

    ```c++
    if (_nextScene)
    {
        setNextScene();
    }
    ```

    This code fragment prompts that if we write a statement to switch scene, it will take effect only in the next frame.

- Push matrix.

    ```c++
    pushMatrix(MATRIX_STACK_TYPE::MATRIX_STACK_MODELVIEW);
    ```

    ???

- Update the physics world if there is.

    ```c++
    #if (CC_USE_PHYSICS || (CC_USE_3D_PHYSICS && CC_ENABLE_BULLET_INTEGRATION) || CC_USE_NAVMESH)
        _runningScene->stepPhysicsAndNavigation(_deltaTime);
    #endif
    ```

- Render the scene (the actual work of "draw scene").

    ```c++
    _renderer->clearDrawStats();
    _runningScene->render(_renderer);
    ```

- If there is a notification node, draw it.

    ```c++
    if (_notificationNode)
    {
        _notificationNode->visit(_renderer, Mat4::IDENTITY, 0);
    }
    _renderer->render();
    ```

- Pop matrix.

    ```c++
    popMatrix(MATRIX_STACK_TYPE::MATRIX_STACK_MODELVIEW);
    ```

    ???

- Swap buffers

    ```c++
    if (_openGLView)
    {
        _openGLView->swapBuffers();
    }
    ```

gha_language: CSS


text:
## Ferp Middleware

### logger(spacing)

The `ferp.middleware.logger()` middleware lets you log out your state for every update.
Handy for debugging, but probably not good in production.

It optionally takes a number argument for spacing, passed into [`JSON.stringify`s third parameter](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/JSON/stringify#Parameters).

## immutable()

Using the `ferp.middleware.immutable()` middleware lazy-freezes your state to guarantee immutability.
Be aware that if you have any mutating state objects, this will throw an exception.
Only use this if you can guarantee that all objects in the state are immutable.

repository: gitter-badger/ferp

repo_name: gitter-badger/ferp


text:
We have an encrypted PVC, which is great, but let's validate that we cannot access this encrypted volume directly.

### Step: Validating a secure PVC
We're going to see if we can access the secure PVC directly from the host. We'll mount the Portworx volume directly on the host so we can see if it's possible access the data.

Start by setting the PVC name in an environment variable.

```
PX_VOL=`kubectl get pvc -o jsonpath='{.items[1].spec.volumeName}'`

```{{execute T1}}

The Portworx CLI gives us the ability to attach and mount a Portworx volume directly on the host. Let's see if we can do this with our encrypted volume.

```
ssh -o "StrictHostKeyChecking no" node01 pxctl host attach $PX_VOL
```{{execute T1}}

You will get the following error message.

`attach: crypt_activate returned error with code -1`

The volume cannot be attached as it is encrypted preventing access to the data.

repository: portworx/katacoda-scenarios

repo_name: portworx/katacoda-scenarios


text:
# bam2circos
Visualize your BAM alignments with Circos

# Genbank identifiers
Circos does not support the vertical bar `|` character in the reference name. Therefore, if your BAM file contains reference names of the format `gi|9630643|ref|NC_001918.1|`, you will have to remove the vertical bars from your BAM file. An easy way to do this is with the following one liner given that your BAM file is called foo.bam and you have samtools version < 1.

```bash
samtools view -h foo.bam | perl -pe 's/gi\|\d+\|ref\|(\S+)\|/$1/' | samtools view -bS - | samtools sort - foo.reformat
```

If you have samtools version >1, change the `samtools sort` command to the following `samtools sort -o foo.reformat.bam`.


text:
---
layout: post
title: 'SQLite, Content Providers, & Thread Safety'
date: 2012-10-11
permalink: /2012/10/sqlite-contentprovider-thread-safety.html
related: ['/2012/05/correctly-managing-your-sqlite-database.html',
          '/2012/06/content-resolvers-and-content-providers.html',
          '/2012/07/understanding-loadermanager.html']
---
A common source of confusion when implementing `ContentProvider`s is that of thread-safety.
We all know that any potentially expensive query should be asynchronous so as not to block
the UI thread, but when, if ever, is it OK to make calls to the `ContentProvider` from
multiple threads?

### Threads and Content Providers

The documentation
on ContentProviders warns that its methods may be called from multiple threads and therefore
must be thread-safe:

> Data access methods (such as `insert(Uri, ContentValues)` and
> `update(Uri, ContentValues, String, String[]))` may be called from many
> threads at once, and must be thread-safe.

In other words, Android **does not** synchronize access to the ContentProvider for you.
If two calls to the same method are made simultaneously from separate threads, neither
call will wait for the other. Requiring the client to deal with concurrency themselves
makes sense from a framework developer's point of view. The abstract `ContentProvider` class
cannot assume that its subclasses will require synchronization, as doing so would be
horribly inefficient.

### Ensuring Thread Safety

So now that we know that the ContentProvider is not thread safe, what do we need to
do in order to eliminate potential race conditions? Just make every method
`synchronized`, right?

Well... no, not necessarily. Consider a ContentProvider that uses a `SQLiteDatabase`
as its backing data source. As per the
documentation,
access to the `SQLiteDatabase` is synchronized by default, thus guaranteeing that
no two threads will ever touch it at the same time. In this case, synchronizing
each of the ContentProvider's methods is both unnecessary and costly. Remember
that a `ContentProvider` serves as a wrapper around the underlying data source;
whether or not you must take extra measures to ensure thread safety often depends
on the data source itself.

### Conclusion

Although the ContentProvider lacks in thread-safety, often times you will find that
no further action is required on your part with respect to preventing potential
race conditions. The canonical example is when your ContentProvider is backed by
a `SQLiteDatabase`; when two threads attempt to write to the database at the same
time, the `SQLiteDatabase` will lock itself down, ensuring that one will wait until
the other has completed. Each thread will be given mutually exclusive access to the
data source, ensuring the thread safety is met.

This has been a rather short post, so don't hesitate to leave a comment if you have
any clarifying questions. Don't forget to +1 this post below if you found it helpful!

repository: nickbutcher/AndroidDesignPatterns

repo_name: nickbutcher/AndroidDesignPatterns


text:
Figures generator
=================

[![GitHub](https://img.shields.io/github/license/prise-3d/figures-generator?style=flat)](https://github.com/prise-3d/figures-generator/blob/master/LICENCE)

# Description

The objective of this project is to facilitate image processing for figure generation within different papers written in LaTeX.

# Current projects

Specific instruction for each current projects are available:

- [`mon-estimator`](https://github.com/prise-3d/figures-generator/blob/master/mon-estimator/README.md)
- [`svd-entropy`](https://github.com/prise-3d/figures-generator/blob/master/svd-entropy/README.md)