Docker on Core Linux

Docker Running on Core Linux

Is it possible? … Yes? However I didn’t write down some of the pre-requisites for the Core Server (whoops, maybe one day I’ll redo it from scratch). But if you do manage to get the base binaries installed this post should be helpful for all the caveats I faced along the way…

In my previous post I mentioned that Docker wouldn’t run unless it was 64bit machine, so I created a Core Linux 64 bit image and showed how to get the base OS up and running… but what about Docker itself.

Now I got this “working” but I didn’t exactly write down all my steps (it took a long time to figure out). From looking at the VM’s history looks like I simply used the tc account to download and extract the base Docker binaries:

now this doesn’t tell me the relative path I was on when some of the relative paths are called, but I do know it was the tc account so some safe assumptions can be made.

Reviewing my AI chat and notes I took, and getting it running again after a reboot, it seem after the “install” (copy base files to path shown above image, line 51) I also added “var/lib/docker” and “etc/docker” to the filetool.lst file, so they stay persisted after reboot. Strangely only /var/lib/docker is populated, but I can’t see how that’s the case from the history review. I was pretty positive the script itself failed to execute… I really should start from scratch else this post will be a bit useless…. butt…. F*** it….

The next issues seems to be tired to cgroups and certificates…

Fixing Cgroups Error

sudo mount -t tmpfs cgroup_root /sys/fs/cgroup/
sudo mkdir /sys/fs/cgroup/devices
sudo mount -t cgroup -o devices none /sys/fs/cgroup/devices

That should be it… but we need this to be persisted and auto run at boot time so we don’t have to do this every time…

sudo vi /opt/dockerd.sh
i
mount -t tmpfs cgroup_root /sys/fs/cgroup/
mkdir /sys/fs/cgroup/devices
mount -t cgroup -o devices none /sys/fs/cgroup/devices
ESC
:wq
sudo vi /opt/bootlocal.sh
*append with*
/opt/dockerd.sh
:wq
sudo chmod +x /opt/dockerd.sh
filetool.sh -b

The next issue seems that docker would load, but when pulling a container to load it would just seem to fail complaining about certificates.

Fixing Certificate Error

I found the point in my notes rambling with AI when I figured it out…

“NO F***KIN WAY!!!!!!! https://stackoverflow.com/questions/75696690/how-to-resolve-tls-failed-to-verify-certificate-x509-certificate-signed-by-un I read this thread and read the answer by Andrei Nicolae… which said just durr copy ca certs to /etc/ssl/certs I was like, I bet docker is hard coded to look there, which is why it was first suggested but all other apps on tiny core linux know to use /usr/local/etc/ssl/certs, so yeah docker never was using the expectects paths liek I suspected from the begining cause we manualy installed it for a OS not supported. so with this I did sudo mkdir -p /etc/ssl/certs sudo cp /usr/local/etc/ssl/certs/* /etc/ssl/certs sudo pkill dockerd sudo dockerd & sudo docker pull hello-world and guess what it finally freaking worked”

But I realized instead of copying them I could just make a symlink

sudo mkdir /etc/ssl/
ln -s /usr/local/etc/ssl/certs/ /etc/ssl/

I simply placed these lines in /opt/dockerd.sh file I created earlier, rebooted and verified that /etc/ssl/certs was populated with certs and it was.

And finally…

Running Dockerd

sudo DOCKER_RAMDISK=true dockerd &

Pulling Image

sudo docker pull hello-world

Running Image

sudo docker run --rm hello-world

Yay we actually ran a container from Core Linux.. Mind Blown… I swear I had it all running at only 90MB of RAM, but checking now show 116MB Bah…

To get Docker to run at boot my final /opt/dockerd.sh looked like this:

Make Sure your DFSR is working!

This one is kind of interesting. I use a replicated test environment to validate things, it works great. I was using the domains sysvol to quickly copy some text between member servers, however to my amazement I was not seeing the same contents from two different member servers even though both of them validated their security with my domain (nltest /sc_verify:domain)…

It wasn’t until I checked both DC’s that I noticed one member server was seeing a SYSVOL from DC 1 and the other member server was seeing contents from SYSVOL from DC2.

Now, all DC’s have the same SYSVOl contents right?! So what gives?

You may have already guessed it, DFSR issues…. if you know the title didn’t give anything away…

Which lead me to this nice MS support page.

The most important line from it is this…

For /f %i IN ('dsquery server -o rdn') do @echo %i && @wmic /node:"%i" /namespace:\\root\microsoftdfs path dfsrreplicatedfolderinfo WHERE replicatedfoldername='SYSVOL share' get replicationgroupname,replicatedfoldername,state

with this my DC’s reported a state of 2 (well that could explain the diff I was seeing)

which lead me to this nice MS Support page. 🙂 These are usually better than most I’ll admit. I followed the steps on “How to perform an authoritative synchronization of DFSR-replicated SYSVOL (like “D4″ for FRS)”

Until I realized that core doesn’t come with DFSR mgmt tools, even if you install the AD role… So for the most part I skipped the steps stating run “DFSRDIAG POLLAD” cause it’ll fail to run, as it does not exist

Maybe some one out there is smart enough to know the answer…

Creating, requesting, approving, installing Certificates on IIS Core

One way:

  1. Open Certificates Snap-in from Remote Management computer.
  2. Connect to remote computers Machine store (Core-IIS).
  3. Right click the Personal Store object (folder) -> All tasks -> Advanced Operations -> Create Custom Request…
  4. Pick Enrollment Policy (Custom Request for 3rd Party CAs) I have internal CA, So I picked AD Enrollment Policy.
  5. Template – Web Server | PKCS #10
  6. Click Details to expand the AD EP – Web Server template properties (Make sure you enter a common name of the host name of the server, and SAN names for any sites you plan to use this certificate for)
  7. Save the Request file.
  8. A) Navigate to your CA sign the certificate. (In my case I have web enrollment, so I simply navigated to my CA web page and picked custom request, then opened the request file in notepad and copied the request contents into the text box of the web request, after issued, saved a copy in Base64 format)
    OR
    B) Open the CA snap-in, Right click the CA -> All tasks -> Submit a new Request, Save the issued cert file.
  9. Right click the Personal store on the remote Certificates Snap-in again, select All Tasks -> Import.
  10. Your Certificate is ready for use on the Website binding section of IIS.

Second way:

  1. Creating an INF file to set the certificate properties

    [Version] 
    Signature="$Windows NT$"
    
    [NewRequest] 
    Subject = "CN=SERVER.CONTOSO.COM"   ; For a wildcard use "CN=*.CONTOSO.COM" for example 
    ; For an empty subject use the following line instead or remove the Subject line entierely 
    ; Subject = 
    Exportable = FALSE                  ; Private key is not exportable 
    KeyLength = 2048                    ; Common key sizes: 512, 1024, 2048, 4096, 8192, 16384 
    KeySpec = 1                         ; AT_KEYEXCHANGE 
    KeyUsage = 0xA0                     ; Digital Signature, Key Encipherment 
    MachineKeySet = True                ; The key belongs to the local computer account 
    ProviderName = "Microsoft RSA SChannel Cryptographic Provider" 
    ProviderType = 12 
    SMIME = FALSE 
    RequestType = CMC
    
    ; At least certreq.exe shipping with Windows Vista/Server 2008 is required to interpret the [Strings] and [Extensions] sections below
    
    [Strings] 
    szOID_SUBJECT_ALT_NAME2 = "2.5.29.17" 
    szOID_ENHANCED_KEY_USAGE = "2.5.29.37" 
    szOID_PKIX_KP_SERVER_AUTH = "1.3.6.1.5.5.7.3.1" 
    szOID_PKIX_KP_CLIENT_AUTH = "1.3.6.1.5.5.7.3.2"
    
    [Extensions] 
    %szOID_SUBJECT_ALT_NAME2% = "{text}dns=computer1.contoso.com&dns=computer2.contoso.com" 
    %szOID_ENHANCED_KEY_USAGE% = "{text}%szOID_PKIX_KP_SERVER_AUTH%,%szOID_PKIX_KP_CLIENT_AUTH%"
    
    [RequestAttributes] 
    CertificateTemplate= WebServer
  2. Compiling the INF file into a REQ fileThe following command-line command will generate key material and turn the INF file into a certificate request.
    certreq –new ssl.inf ssl.req

    Once the certificate request was created you can verify the request with the following command:

    certutil ssl.req
  3. Submitting the REQ file to the CA: if the CA is reachable via RPC over the network, use the following command to submit the certificate request to the CA:
    certreq –submit ssl.req

    You will get a selection dialog to select the CA from. If the CA is configured to issue certificates based on the template settings, the CA may issue the certificate immediately.If RPC traffic is not allowed between the computer where the certificate request was created and the CA, transfer the certificate request to the CA and perform the above command locally at the CA.

    If the certificate template name was not specified in the certificate request above, you can specify it as part of the submission command:

    certreq -attrib "CertificateTemplate:webserver" –submit ssl.req
  4. Installing the certificate at the IIS or ISA computer: Once the certificate was issued and is available as a file on the target computer, use the following command to install it.
    certreq –accept ssl.cer

    The installation actually puts the certificate into the computer’s personal store, links it with the key material created in step #1 and builds the certificate property. The certificate property stores information such as the friendly name which is not part of a certificate.After performing steps 1 to 4 the certificate will show up in the IIS or ISA management interface and can be bound to a web site or a SSL listener.

*UPDATE* Powershell – I love PowerShell. If you’d like some more automated scripts to help with such a task. Please see this Blog Post by Adam Bertram in which he provides a link to his gitHub page with the required scripts.

Thanks Adam for this fine work. I might just make a pull request to make some changes/tweaks to the scripts. Amazing the neat little tricks I learn from reading other peoples code. 🙂