Re: Dont understand how the two things are similar
Situation 1) A person has a thing, or skill that another person does not (Dump a diskette to an image file, for emulation), but needs to have done in order to play a game they want. (because the game is on a moldering old diskette they cannot read anymore)
Situation 2) A person has a thing or skill that another person does not (Knows how to configure a small lowpower dedicated machine to make it run as a dedicated game server), but needs to have done in order to play a game they want. (because they need a game server running to play a game, but dont have a lot of space or money to invest in hiring or powering one.)
Re: How to do it
It's pretty simple. You can often SSH into these boxes, and they typically have a linux kernel running. Just get the outputs of
cat /proc/cpuinfo
cat /proc/swaps
free
chroot
which will tell you how much free memory there is, if swap is enabled and how much, and what the CPU flavor is (and how fast in useless bogomips). running chroot with no parameters lets you know if the busybox install has chroot applet baked in. If it does, all is golden.
After that, I use a minimal debian userspace chroot, downloaded on a different linux machine that has access to a package manager. (The network appliance does not have the toolchain, and likely has only a minimal busybox installed.) You do that with debootstrap using the --foreign flag.
debootstrap is an old 'network installation bootstrapper' that is GREAT for creating the initial chroot environment. The --foreign flag tells debootstap that you are downloading packages for an architecture that is different than the one you are running on. It enables the use of the --arch flag, where you get to specify the architecture.
In the case of my western digital mycloud nas (my current toy I am playing with), the architecture is armhf, because cpuinfo reports vfp and vfpv3, meaning the chip has an fpu baked in, and the kernel supports it. so, I used this on my workstation:
debootstrap --foreign --arch armhf ~/mycloud_chroot jessie
http://ftp.debian.org/debianThat tells debootstrap that I am downloading for foriegn architecture (dont do the config stage, just download packages), the architecture is armhf, where I want the files stored, what branch, (in this case, jessie), and what server to contact with the package manager to get packages. One of the useful features of doing it this way, is that a binary for debootstrap is put in a folder in the resulting new root filesystem in a folder called debootstrap. This allows you to continue the process on systems that lack the command, and have no access to a package manager to get it.
It will then download all the packages needed for a very bare-bones, console only userspace for Debian Jessie on that architecture.
Once it is done, you use scp or whatever sftp transfer tool you want to copy the chroot folder to the device's long term storage. (for routers, I suggest putting a USB thumb drive on, and using that.) Once there, we switch to the device's console, and do the following:
(Mount /dev /proc and /sys for the chroot)
mount -o bind /dev /home/(Path to the chroot folder you sftp'd in)/dev
mount -t sysfs none /home/(path to chroot)/sys
mount -t proc none /home/(path to chroot)/proc
(then enter the chroot and continue setup with debootstrap by running the config stage using the --second-stage flag.)
chroot /(path to chroot) /bin/bash
cd debootstrap
./debootstrap --second-stage
This will run all the config scripts. It is normal for the chroot prompt to report "I have no name!" in the prompt. this is because the root user has not been properly set up. You cannot do that until AFTER debootstrap has been invoked to configure the base system and give you access to the basic toolkit. Once it is done, use su to switch to the root user, (you might need to use adduser to create it) then use passwd to set the root password. exit the chroot, then re-enter it again. All will be well after that.
Once you are back in the chroot again, you should now have access to nano, and a few other goodies. Take the time to configure the /etc/apt/sources.list so that it looks sensible to you, then issue an apt-get update to get an up to date package list. Then install whatever packages into the chroot you want with apt-get install method.
Once you have the packages installed you want, now it is time to make some old school init scripts. The chroot comes alive after the system has gone through the kernel init, and the system is already running, so normal init systems wont work. You have to cobble together something similar to sysvinit initscripts, like an /etc/init.rc, which takes care of starting server daemons, getting chron running, etc. Once you have that written, exit the chroot, and enter it again, but instead of invoking /bin/bash to land in a shell, we want to invoke our new init script.
chroot /home/(path to chroot) /etc/init.rc
This will give us a test-run of our system coming up. I suggest re-mounting /proc and /sys again in the init script, because sometimes they lose the magic when entering the chroot. Dont know why. They just do. Same with /dev/pts for some reason.
You can invoke another instance of sshd to run inside the chroot using this init script, and I highly encourage it, just run it on a different port. This will let you ssh into the chroot as if it were the real root from your workstation after the system has run its init script.
Once you are sure the chroot is ready for actual use, we need to have a way to execute it on startup of the embedded device. This is where it gets device specific.
On routers, almost all have the source-tree for the firmware image available online. This will let you build a new flashable image that contains a modified init script that calls a script on the external storage. If the call fails, it does not harm the router, it just does not launch the chroot. If it succeeds, it starts the chroot automatically. We can even have this fail gracefully with a check for existence. Either way, the change is harmless, but needs a full rebuild of the image from source. It takes time and is annoying, but necessary.
For things like a NAS, that have native access to permanent storage, we can abuse one of the chron jobs executed at startup to invoke our chroot's startup on the last leg of boot, and add a trap to prevent it being executed a bazillion times by chron in the script. (write a dummy file to /tmp using touch, and if the file exists, do nothing-- otherwise, create dummy file then invoke the chroot. That kind of thing. Every time the job runs after that, it will do a check, see the file in /tmp, do nothing, and end)
The chroot's fake root file system will act just like a real root filesystem to whatever userspace toolchains and packages you see fit to pull from the package repo. You can even set up a vnc server and run a GUI if you really really want to. (I dont see a need. the console is good enough)
Once you have it set up, you can set up and use any game daemon you want, using the normal linux installation procedures.
Because there are lots of steps involving creating init scripts, and abusing chron jobs or recompiling sources for flashable images to have an init hook, this isnt something most users would feel comfortable doing themselves, hence the idea of doing it as a service for free by mail.
You send in a box you want to putter around with, I set up a suitable chroot on it, put a sticky note on top saying what port and default root password I configured the chroot's sshd with, and mail it back. You get it in the mail, power it up, log in with ssh, change the password to whatever the hell you want, and off you go.
If you dont like debian, you can use any of the "based on debian" distros instead, like ubuntu. Just substitute an ubuntu mirror and version identifier instead of the debian ones when invoking debootstrap.
Author
Topic: Should I start a "by mail" game server config service? (Read 1559 times)