NixOS, Root SSH install media for bootstrapping headless system

I've needed a CI Build system and a self-hosted Git repo for a while now. By chance, a friend was selling an old blade server, so I grabbed it. We have the space in the house, but we don't have anywhere to put a VGA monitor/keyboard. So, I need an install image that will launch sshd, permit a root login (with some default password) that I can use to bootstrap the system.

Additionally, after talking with some other friends about making an automated deployment system to reduce the amount of manual maintenance I need (I need something I can just fire-and-forget) rather than using Docker to deploy my services, it was suggested that I should look into called NixOS.

Looking it over, I'm very interested: the description's of Hydra sound like they solve a lot of problems I've had with CI/Build environments - notably, that dependencies aren't tracked by the build system and there's no way to control changes to the build environment.

NixOS has a built in tool for building custom liveCDs, which should be perfect for the headless installer... Except for one problem... NixOS's documentation kinda sucks. Which is a shame.

Thanks to some help from the #nixos irc channel on freenode, and the manual, I've managed to build that image.

1. These steps can only be performed from an existing nixos environment.

2. Check-out the nixos-small repository, then cd into it.

git clone --branch nixos-16.09-small https://github.com/NixOS/nixpkgs-channels.git nixpkgs

cd  nixpkgs/nixos

3.  Create a configuration file modules/installer/cd-dvd/installation-cd-ssh.nix

{ config, lib, pkgs, ... }:
{
  imports =
    [ ./installation-cd-base.nix
    ];
  environment.systemPackages =
    [
      pkgs.vim
    ];
  services.openssh.enable=true;
  services.openssh.permitRootLogin="yes";
  systemd.services.sshd.wantedBy = lib.mkForce [ "multi-user.target" ];

  users.extraUsers.root = {
    initialPassword = "PregeneratedPassword";
  };
}

4. Build the iso

 nix-build -A config.system.build.isoImage -I nixos-config=modules/installer/cd-dvd/installation-cd-ssh.nix

Done.

Learning Pyglet

Segfault, an impasse.

SDL2.0 to create a modern OpenGL context.

I've been having difficulty finding documentation for SDL2.0 so I'm going to record the invocations here as I find them... (With thanks to everyone who's helped me find them)

Once I've got a better (and full) handle on it I might try to right a well written tutorial... For now I'll just record my findings.

Requesting a given version of OpenGL

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MAJOR_VERSION,4);

SDL_GL_SetAttribute(SDL_GL_CONTEXT_MINOR_VERSION,2);

This appears to disable the compatibility profile/enable the core profile only. I need to check this though.

Creating an OpenGL context...

int width = 640; int height = 480;

SDL_Window* pWindow;

SDL_GLContext context;

int other_flags = 0;

pWindow = SDL_CreateWindow("Title", 

SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, 

width, height, 

SDL_WINDOW_OPENGL|other_flags);

context = SDL_GL_CreateContext(pWindow);

Verifying that the Context was created successfully...

const unsigned char* version = glGetString(GL_VERSION);

if (version == NULL) {

// Failed to initialise, error logging here

exit(-1);

}

Flushing pipeline...

SDL_GL_SwapWindow(pWindow);

Todo: Figure out how to compile/link a shader.

Crossplatform Development?

So. I'm finally going back to C++... and remembering why I learned Python to get away from certain things.

Most notably is the pain of setting up Makefiles by hand. Still. I think I've hit on something. Relative to my project's directory...

I have a folder for my build which contains a Makefile customised for that platform. On windows this is...
mingw_debug/Makefile:

CC=mingw32-gcc.exe
CXX=mingw32-g++.exe

CFLAGS=-g -O0 -Wall -pedantic -Wno-long-long
LIBS=-lmingw32 -lSDLmain -lSDL -lopengl32 -lphysfs

DLL=SDL.dll libphysfs.dll

include ../src/Makefile.core

It explicitly specifies CC and CXX because I tend to use Cygwin as a replacement shell and it allows me to use make instead of mingw32-make.exe.

src/Makefile.core

SOURCES=hello.cxx
OBJECTS=$(SOURCES:.cxx=.o)
DEPS=$(OBJECTS:.o=.d)

CFLAGS+=-I../src/

all: Coulomb.exe $(DLL)

-include $(DEPS)

Coulomb.exe: $(OBJECTS)
$(CXX) -o Coulomb.exe $(OBJECTS) $(LIBS)

define cc-command
$(CXX) -o $@ -c $< $(CFLAGS)
endef

define depend-command
$(CXX) -MM -MF $(patsubst %.o,%.d,$@) $< $(CFLAGS)
endef

data/%.o: ../src/data/%.cxx
$(depend-command)
$(cc-command)


%.o: ../src/%.cxx
$(depend-command)
$(cc-command)

%.dll: ../%.dll
cp $< .

.phony: all clean


clean:
rm -rf *.exe
rm -rf *.o
rm -rf data/*.o
rm -rf *.d
rm -rf data/*.d
rm -rf *.dll

Unfortunately I still don't really know what I'm going to do with this set up yet. I'd appreciate any comments on the Makefile set up though.

DuelFieldStars v1 release

I have decided that the DuelFieldStars project no-longer interests me.

Originally I was only going to implement the features it has now and everything else, that I did not implement, were extra things I added to my ambitions. So I am quite happy calling it here.

This has also given me opportunity to play with py2exe. I think in the future I will try to organise my project with py2exe in mind.

Windows distributable: https://github.com/downloads/Tarinaky/DuelFieldStars/duelfieldstars_win_v1.0.0.zip
Clone source (reqs. Python2.7 and Pygame): https://github.com/Tarinaky/DuelFieldStars/tarball/v1.0.0

I guess this means I need to look for a new project now...

"Im Nebel einer Ungewißheit"

The game now has a... minimal implementation of 'fog of war'. At present the three reports can penetrate the fog, but it shouldn't be too hard to adjust them.

The basic idea is that you can only 'sense' out to your Sensor Technology rank in range. You can research Stealth Technology to allow your ships to effectively negate enemy Sensor Tech - meaning that the 'fog of war' shown in the above image is an optimistic estimate, rather than absolute. Fortunately you can always detect things in the same game tile as a friendly ship or world.

At the moment it is still somewhat... buggy, but hopefully this week I can get it tightened up to work more closely with how it should.

As you begin with 1 game tile of sensor range and 3 tiles of movement range the intention is, in the early game, to be very 'Star Trek'/submarine, with unexpected encounters near worlds while ships sail past each other undetected in deep space. Towards the late game there will be Special Technology paths like remote sensor platforms that can remove this uncertainty... But you always have the option of concentrating on Stealth (which, I hope, will play very nicely with the Jump Drive tech path) to allow out-manoeuvring on the offense.