Month: December 2019

Posted on

Minecraft Server, Week 6: Press Start

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I almost posted one of my backlogged posts, but I managed to pull together something to continue this project one more week. Let’s get started!

I don’t know where to begin on this one. Last week, I left off with reinstall after reinstall, trying to fix some error I kept seeming to get. I gave up after wrecking my bootloader during one last attempt to fix everything, forcing the machine to depend on booting to live media, such as my Puppy Linux CD. I stuck around to determine that Ubuntu wasn’t accidentally nuked alongside Micro Core, so I was at least partially appeased on that front.

Sunday came and I thought I would try one more time. I had done some research on GRUB 2 (GRand Universal Boot Loader). Boot loaders are programs that take charge after the BIOS select a drive to boot to. They are in charge of starting the operating system. GRUB is designed for environments with more than one OS, like the one I seem to have ended up with. It is worth noting that GRUB and GRUB 2 are two different boot loaders that serve the same purpose, they both refer to themselves as GRUB, but some places say you can get in trouble if you use support for one on the other. From what I can tell Arch Linux is one of the few distros that use the first one.

I started up Puppy Linux and suffered while trying to find the terminal. That little distro does not follow many of the conventions I’m used to as is! Bad dog! I researched how to repair GRUB and when I looked in my MineOS drive, I found… what looked like a fully functional boot loader.

Annoyed, I told the BIOS to boot to the old SSD before the HDD with the bricked GRUB install. It worded. I was able to boot to MineOS, but I still got a corrupt terminal pseudo-window interface: the configuration console. Sometime after I seemingly bricked my machine, I had the thought that I might not have really had an error to fix all along. I was hoping everything was just one unknown away, and that was it.

MineOS is fairly minimal on the host machine. It really shines in its Web Interface. You connect to its IP with https at port 8443 and sign in using the account you set up during your first boot. I tried that and got a page that got stuck loading. Different computers didn’t help either. I gave up and resolved to put the finishing touches on a stand-alone post I have written after pinging my contact with a picture of the error message and corrupt-looking screen I was having trouble with.

Hours passed, and I eventually got a celebratory reply of all things. I decided to humor him with one last attempt on connecting to the previously tried IP and port. It worked. I seemingly didn’t do anything differently, but it worked on me. I went over to the other towers I had previously tried it on, and it worked on those. It did not, however, like Android Firefox on my tablet, but the browser built into LastPass was accepted.

About this time, I investigated one of the features of MineOS inherits from its parent distribution, Turnkey Linux: Let’s Encrypt. Let’s Encrypt seems to be a free SSL certificate authority, if I got my terms all correct. If you already know what you’re doing or are following a set of instructions and don’t care about learning, you can reportedly have one within ten minutes. The only issue for me was that the application script gave me a bit of a head scratcher. It wanted a domain, and I didn’t know what to put. In the end, I figured I wouldn’t be exposing the login port to the Internet anyway, so I can wait on setting that up.

The web interface itself is well polished. I still don’t know what all I am looking at, but it is a whole lot easier to behold than a command line. Exploration is also much easier. I set up a test server, trying to get something going on a port other than 25565, the default Minecraft port, but some diagnostics and research later, and it looks like part of the Web Interface’s design principals exclude it from being able to open additional ports, mainly that not all operating systems it can possibly be installed on keep track of open ports the same way. I suppose that keeps the dabblers contained in a field of relative protection, leaving advanced use to more seasoned computer users.

I moved my test server to the default port and had a volunteer try again. It worked, and this time when I expected it to work.

MineOS has an import feature that’s supposed to be fairly smart when it comes to importing archived servers. .ZIP files were confirmed, but I wanted to feed it a tarball and see what would happen.

I took the server of interest offline and –very important– made a copy separate to any backups I may have had. I then started weeding out things that wouldn’t make it over to MineOS, such as the WorldBackups folder, the start script and its backup, and copies of the datapacks we are running. The tarball came out to 1.9GB.

Transportation was a hassle. I didn’t have the patience to set up SSH correctly, so it gave me a warning if I tried to copy. The old host machine, my father’s computer running Linux Mint, didn’t have an SSH server on by default, so I couldn’t grab it from the new server. I tried my 1TB external drive, but when I finally got it mounted, it was read only, likely because of the way it was formatted. Two additional USB sticks were too small, but I could get it onto an external hard disk drive we have around with plenty of room.

Issues persisted. The MineOS terminal did not want to mount my storage device, and when it did, it wasn’t polite about where it put it. I still don’t know where it was hidden, but one search did turn something up I know for a fact was on the external HDD. For a few actions, like mounting/umounting or listing the contents of some directories, I required root access, but sudo doesn’t look to be a thing here. I used the su (substitute user) command to switch to root, something that should never be done lightly. I even tried booting to Ubuntu and manually copying the .tar.gz file over, but I had some kind of error I have no clue how to address.

In a frustrated fit of doubt, I suggested I may just move the hard drive over to my father’s machine and copy it over to the import directory manually. It actually sounded worth a shot, so I did it. It worked.

I booted the server machine and found a file all ready to import. I set it up, and had a volunteer log in to a brand new world– It was supposed to be the preexisting world. I ended up moving the drive back over to my father’s computer only to discover that it had basically unpacked my improperly compressed tarball and stuck a new server at the root.

I was not pleased. I manually moved the different elements over to the new hard drive and saved each piece. Not all parts had counterparts. I kept the MineOS exclusive files intact, while grafting in the original server’s files. The World file was spelled world (lower case w), but the hardest element was the properties file. For that one, I actually had to evaluate it line-by-line.

Finally, after six weeks worth of work, I had the server on its own dedicated server. I started it back up, and had my volunteers examine the world. So far, all systems appear normal. I plan on keeping on its original Minecraft version for at least a day and I want to make a restore point or backup or whatever they call it. I just need to learn the MineOS Web Interface.

I learned a lot in this project. If it weren’t for this blog, I would likely have given up long ago and just hosted it from my own machine. If it weren’t for my time in MicroOS, the last push I made could have easily have taken two or three more weeks. I’m glad it’s over in time for New Year. And now, I present the newest member of my little computer family: ButtonMash!

Final Question: There are a few details left to polish, but I do not plan on covering them. Do you want me to change my mind?

Posted on

Minecraft Server, Week 5: MineOS

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am finishing this project one way or another ™. Let’s get started!

I’m told that when I encounter a problem and a short, easy solution, I tend to keep tunneling on through the mountain until I break out the other side.

Project history: I spent two weeks generating four weeks worth of content, and now I’m back after two weeks of working on other stuff, and I’m ready to make it work. Somehow.

I came back to Micro Core and tarballed my progress and took another look at those Oracle Java install scripts. The more user-friendly looking one looked to be only for Java 7, and I need Java 8+. The other one wasn’t too hard to get working. I got the .tze and some kind of file with legal in the name. Both went in tce/optional, and… nothing. No successful install, no error messages, just nothing. I reached out to my Micro Core contact, but he was busy with other things, so I decided to change directions entirely.

I will say that in my experience with Micro Core, I mined up a lot of valuable knowledge, but it is time to be water and flow around the mountain.

Enter MineOS.

MineOS is toted as so easy, you can have a proper server for yourself on old hardware, even if you don’t know what you’re looking at when facing anything past what you learned by Kindergarten. I’m sure this will work.

I took my target machine into Third Workshop — mostly so I could have a spot to work without the normal household chatter. I also discussed what should be feasible in terms of my next big project. Before I left, I grabbed a nice, Minecraft grass green DVD to burn, as the MineOS site didn’t mention it working with anything else when dealing with physical hardware.

And my problems began. I left my tablet at home when I sometimes pace around the room with it while continuing to research. When I got there and had everything set up, I put the DVD into my laptop drive and spent several minutes trying to figure out how I was going to burn the MineOS ISO. My go-to tool I thought was installed appearently never made it onto my laptop, and my virus scanner was suspicious when I tried downloading a tool to help with the procedure.

I turned to my target machine. As a dual booted system, I can work on one hard drive while keeping the other safe. I booted it to Ubuntu and looked up a Linux tutorial on how to burn a *bootable* disk, as it turns out that not all disk burners can do that. A short tutorial mentioned a tool called Brasero I could use. It should start automatically when trying to burn anything.

A quick search told me Brasero was not installed, so I had my computer apt-get update. Twelve minutes later, it said there were a number of errors. The repositories must have been having issues or something. For some reason, I tried updating again, to similar results. I moved to my laptop and started writing this blog post, introducing the subject. Might as well use the time I have. When that was done, I told it to install Brasero, and the installer spat back an error, saying it was already installed.

I used a microfiber cloth to clean the DVD, as it looked like years on the spindle weren’t exactly the best for it. I burned it and it booted nicely to an option to install or run a live CD. I told it to install, and was given a command line error code I hardly recognized. The thing didn’t even act like it had the CD drive mounted after boot. That or it didn’t want to give it’s boot media up.

A new external hard drive came to my rescue. I moved the files that came with it into a folder on my laptop labeled as bloatware and used a utility I did have on my laptop already to write the installer to my device. It seemed to work just as poorly.

After I got home, I went to continue working on it, and I forgot to move the keyboard and mouse back to the active tower. As a result, I ended up booting correctly to the setup screen. It was only at this point that I recognized the installer as a fancy terminal program that only looks like it’s in something resembling a window. The clue was from a few strange-looking characters on the ASCII table that looked like some sort of boarder.

I wend back and forth over the machine, formatting and reformatting its poor, old 60 GB SSD. I had trouble with GRUB (GRand Unified Boot loader) not installing, so I had a stint of trying to tie into the one on the Ubuntu drive, but it took reformatting while both drives were connected before it accepted the install, but at that, it said it was unclean or something. I figured I could just go on ahead, as the installer wasn’t very imaginative if you did anything other than what it wanted to do.

During the first-boot config, I entered passwords for both the root and mc users. I ran into trouble with getting the network set up, and that’s about where I am now.

I know I didn’t finish like I said I would. It’s been way too long since I started this project that was supposed to take just two weeks. I’ve learned a ton, but right now, a lot of it feels like it’s going to waste.

Final Question: What are you looking forward to giving for Christmas?

Posted on

Minecraft Server, Week 5: Wall of Java (Unsupported Management version)

Good Morning from My Robotics Lab! This is Shadow_8472, and today, I am continuing work on this server project I’m getting a little tired of. Let’s get started!

Timeline: This week was Thanksgiving, and I didn’t apply myself all day every day until Sabbath like I have the past two weeks. I’m also writing after the fact again.

Last week, I said I would drop the nuke. Well, I did. And the refugees I stored in my little silo gave me a world of trouble. All that trouble last week to preserve what I had, and something, somewhere was unaccounted for, and my little backup and restore scripts all for nothing but an exercise in shell scripting.

While I eventually resorted to a clean install, I learned a few lessons. First, tce-load does not like being run with sudo. I should have remembered this, and come up with some creative solution to install nano and anything else I want to download automatically, but I abandoned that venture before perusing it. Second, something with the login data didn’t copy over correctly. Again, I cut this off before figuring out what exactly was going on. One thing I did keep was the hidden .ssh file for my user account.

Speaking of user accounts, I have noticed that project distros tend to give you a two character login, probably so you can get in easily when you have ssh set up with proper keys. BlinkiePie has a default “pi” account as a nod to it being a Raspberry Pi, while Micro Core’s default user name is “tc” as a nod to the flagship version of the distro, Tiny Core. While doing my clean install, I enshrined my favorite boot codes in the as part of the installation script, and came out with no trace of the tc username in with the encrypted passwords.

With only a couple more obstacles, I loaded OpenJDK 8 on as that is the latest version available for “drag and drop” style installation unless I want to try making a .tcz file myself. I made a folder to test run the server .jar file and ran into an exception: “Unsupported Management Version.”

Those three words defined the rest of my week in relation to this project.

Online searches bring up several near misses, but only a single page even contained the error in its entirety. Sometimes it even shows up twice, and it still doesn’t have any answers.

Several people tried to help me across a few Discord servers. One of my earlier help sessions involved trying to execute a HelloWorld! program. It failed, but only because I actually had do this little thing called “compilation.” A copy was scp’ed (Secure cp (copy), a part of SSH) off to Blinkie for compilation, tested, and ran fine when it came back and I wasn’t just trying to execute the source again.

As a test, I tried copying a known good .jar file over from the intermediary server running on my father’s computer. I mounted the hard disk in the same case tried copying a .jar from a known good Spigot 1.13 server. Both gave slightly different versions of Unsupported Management version. The trace didn’t even lead to the same place!

Taking a closer look at version numbers, I found that I was dealing with a seemingly slightly older build of Java than most of my other computers. If so, it might explain why things aren’t working, as Java supposedly only runs on the same or later version as it was compiled for. Besides, I may want to run a plugin or two some time, and it would be easiest if all versions on the server are running off a single version.

Blinkie seems to have the oldest build of Java 8, so I went over there and started setting up Build Tools, a script used in the distribution of Minecraft Spigot. As with anything that tends to spew files everywhere, I contained it in a box (directory). I ran Build Tools, and got a message about low RAM. It needs more than a 32 bit OS can address, and Raspian is a 32 bit distro intended for a 64 bit machine.

Even though Micro Core doesn’t even seem to have a Java compiler available in its repository, I tried running Build Tools straight on Micro Core. I didn’t expect it to work, and it didn’t. At least it provided me with a third Unsupported Management version example to study. I was honestly expecting it to fail due to lack of a compiler.

From here on out, all I’ve done is research. I’ve poked this problem for days, I don’t know how to fix this yet. The first, and most obvious way would be to try Oracle JDK again, but I want to back everything up first, possibly by booting to Ubuntu, mounting Micro Core’s SSD, and using tar on the contents.

Another possibility is just scrapping everything and going with MineOS. It has all the features I’ll want, all packaged up nice and tidy. Backups, updates, premade start/stop scripts for (multiple?) servers. It even has security considerations I haven’t even begun making plans for yet. Anyone can use it with minimal effort. It’s perfect — except that it would feel like a cop out.

One of the reasons I’m doing this project is to learn whatever I need to function as an effective power user in Linux. I’ve learned so much on this one project, and I don’t want to take the easy way out this time. Even when looking at Build Tools again, I understand so much more than when

The other path I think I can develop is making a new .tcz file for a different version of OpenJDK. Since I don’t want to spend forever trying to do it on my own, I am going to try making an account on the Tiny Core forums. The development team reportedly patrols it, so if there’s any place I’m going to get help, that is it. It isn’t secure, so I’ll be using my password manager to generate a whopper for it.

Ultimately, this is a very niche problem. Normally, I like split the different parts when I have most of the plot threads tied off with progress made on the central thread. This post feels more frayed, but it’s a full week’s events. Happy Thanksgiving!

Final Question: Every kind of computer interface has its own set of required basic actions we take for granted after a while. What kind of basic, but not too basic features do you take for granted in your interface of choice?

Posted on

Minecraft Server, Week 4: Progress Backup

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I’m aiming a digital nuke at my progress on this project thus far. Let’s get started!

By the time this post goes up, I hope to have finished the whole project. As I write this post, it’s a little less than a day before part 2 goes live. I feel like I’ve made the least progress in terms of building a product, but I feel like I’ve made the most in terms of learning.

To recap: Part 1 was about assembling the hardware, Part 2 was about picking and installing Micro Core, and Part 3 was about trying to install Java and some of the things I learned that segment.

My goals for this statement only involved backup and later recovery, possibly in time for a quick transition to a working server. On one trip to Third Workshop, I spent a lot of time pacing and writing things down for what I want to save. I copied those over to a directory in a hard drive and even started on a script to automate their unpacking.

Back home, I found my files were missing. Lesson learned: Don’t trust Micro Core with things you want to keep unless you’ve finished setting it up. They will vanish unless protected.

I’d often have two or three topics I’d bounce around between. While looking for files to save, I went searching through the manual and found a more complete set of boot codes so a few things can live on my hard drive proper. While I’d love to do some possibly destructive testing around with the included file backup tool, I cannot risk it until I’ve finished my backup tools and mitigated the risk for when something breaks hideously.

The exact directory and file you can find your boot codes will vary depending on your bootloader. The Tiny Core Linux wiki has pages on a few of them, and if you ever need to know yours, try using the command “sudo ls -ra / | grep <loaderName>”. Sudo keeps you from getting a bunch of error messages from trying to look in a directory your default user account doesn’t have access to. The ls command forms the core upon which the rest of the command is built on. It means to list the stuff in your present working directory. Options come next with r meaning recursive, or all sub-directories, and a searches everything that’s hidden as well. The pipe symbol, |, acts like a funnel, taking the output of the ls command and feeding it into the next element, grep. Grep sorts long batches of data so it only displays lines containing <loaderName>.

I added a few more boot codes, tying several directories to the SSD. During this time, I learned a lot about what is supposed to go where. If I couldn’t find the answer to a question, I’d reach out to whatever help I could reach without making additional accounts. I almost made one for the Tiny Core forums, but I shied away when it would have involved logging in over an unsecured connection. My guess would have been that the site is so old they never bothered, but I think it’s just the admins not caring.

Progress overall was slow. It took me a day or two to figure out how to properly mount a drive and similarly “umount” it. (The n was left out in favor of a slightly shorter command to type.) It took a live chat session with a knowledgeable person to convince me I was looking at something in /mnt I now believe to be a mountpoint and not the automatically mounted drive.

With an ironically stabilizing system, I once again started development on my script. Each time I went to access it at /mnt/sdc1/restore.sh, I had to use sudo to get through an ownership blockade. Plus, with the geometry of the room, I wasn’t all too sure if one of our dogs was going to march right through the thumb drive. I also kept getting errors involving permission –and later ownership after I discovered the -p option– when trying to copy files there.

My next lesson was about how some disk formats don’t support Linux/Unix style ownership. FAT32 is apparently one of those formats that can, at best, only be faked. Since I was dealing with files owned by both Shadow_8472 and root, I’d need to empty off another thumb drive and research a format for them, or find another way to preserve permissions.

I must have reached out to three, four, maybe even five places for help. Somebody suggested I make a tar archive. I figured, “why not.” After all, I would be dealing with a tarball containing Java anyway.

Tar is an older piece of software with a bit of history. Its name stands for tape archive. Webcomic strip XKCD even ran a strip where they teased it for being so convoluted that sysadmins who have been using it for fifteen years still don’t know it by heart — and those commands were already fifteen years old when said admins started using them!

There are more than a few misconceptions surrounding tar. Just because something is archived, doesn’t mean it’s compressed. Zip files popularized that notion. Compression is basically squishing out repeated bit patterns for convenient transport. Archiving collects several files like papers ready to be bound into a single book. The two processes complement each other nicely, usually giving you a single file that takes up less space than the original files in their entirety.

I have no idea of the full power of tar. I just know that it has loads of features, but most of its users will never use them. I can’t help but wonder how many are totally obsolete, but included for lack of an update, or to maintain backwards compatibility.

Armed with these pieces of knowledge added to my collection, I wrote a pair of scripts to grab an arrangement of files I think I will need when I rebuild. I do have it setup to reinstall Nano and Opencss from the repository, but future versions, if needed, can be migrated to be part of the backup along with files that include things like encrypted passwords, boot codes, the whole Minecraft server directory, and more. It all gets copied into a temporary directory, turned into a tarball, and the temp directory removed.

During development of the backup and restore scripts, I stashed a copy or two on Blinky for safekeeping. I would have used one of my Windows machines, but it was just easier and had the same result to use scp to move the files over ssh between two Linux machines. I also noticed PuTTY having some interesting results when using the cat command to concatenate the contents of a file to the terminal. Normally, it keeps track of who you are logged in as to where and what directory you’re looking at right now. It would seem Raspian keeps track of that for you while Micro Core does not. I also found that using cat to show a binary that isn’t in text form could end up sending a command to PuTTY to change the window title, and even corrupt the header on the command line.

And that about brings things up to date. I changed permissions on the scripts so I have to run them as sudo, but while doing so, I accidentally removed one of them. I just so happened to have a backup courtesy of Nano… somehow. I ended up restoring from the Blinky backup, as it was more recent.

My next step is an irreversible one. I need to drop the nuke and start over with what I’ve saved. With any luck, the next post will be the full rebuild, ending with Minecraft running on Micro Core.

This (half)week’s idea sounded simple enough. Just copy the most important files away from the mess I created when I tried to install Java. One required skill snowballed into another, and before it, I had learned a whole slew of skills needed to slither along in the command line.

Final Question: I’ve been dealing with a lot of old computers lately. How old is the computer or other device you’re using right now?

Posted on

Minecraft Server, Week 3: Java

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am once again writing well ahead of the actual publication date. Let’s get started!

As I start this post, I’m still in week 2, and I might even finish this segment in week 2, depending on where a good stopping point is. The following events started early in week 2.

Last week’s post covered installing Micro Core, all the way up to and including a corrupt install of Java. I’m discouraged. I was just one… three… several steps away from finishing this project within my projected timespan of two weeks. I want this server up, but it’s more important to finish correctly. But timetables are near-impossible to stick to when you’re also learning how to use a computer again as if for the first time.

The command line is very different to using a GUI. It’s not toddler friendly, and it requires a ton of memorization. File systems, commands, command flags, file names; during one of my Third Workshop visits, I learned the man command, which brings up a manual for most commands. Micro Core has external documentation, likely for space concerns, so it’s off to the Internet for pretty much anything I don’t get.

Botching the Java install made a big, old mess, and having two copies of the Minecraft jar file made it more awkward when an obsolete backup got involved. I made the decision to nuke the OS and start over. But I didn’t want to just cut it off right there. If I need to start all over, possibly several times, I’m going to want to keep at least some of my progress, after all, I have SSH access from no fewer than three machines, all nicely set up with each one’s public key.

I took it under advisement to start writing a script to rapidly move back in case I need to redo my setup several times. Even if I never use it though, I’ve still learned a lot by dissecting my own work.

For starters, I spent an afternoon and early evening working at a trickle, writing down elements I needed to save. I moved them all to a thumb drive located at /mnt/sdc1, and found I had lost all my progress when I got home and plugged everything in. At least I have a picture of the tiny whiteboard I was taking notes on.

Mastering persistence is one of the greatest and most important challenges to working with the Tiny Core family, alongside finding someone who knows how to do the thing you’re trying to do in a close enough circumstance. With most available documentation aimed at baseline computer-literate GUI users, a GUI native lost in a CLI world has to sift through multiple forums and documents to find relevant answers. If I had to guess, I’d say it feels like a quarter of the Tiny Core help out there talks you through different menus of the default programs while maybe one out of sixteen is a Micro Core specific way of doing things. Note: I think it’s actually closer to one out of eight GUI special tutorials.

Investigating persistence, I learned a lot about the file structure: too much to regurgitate for review here all at once. I’m not even sure it’s even fully digested. The root file directory has a bunch of files, each with an intended purpose. When I reinstall Java, it’s going in /opt, for example. TCL has a special directory called tce where all the packages go for reinstalling everything on bootup. There’s also some network of links I haven’t even begun to explore; I just know they make it possible to pull off running the OS from a couple different files instead of having everything scattered everywhere.

Vanishing files had me for at least a couple days in parallel with other issues. I read that writing files to physical drives makes them persistent by nature. After my work went poof from my USB stick, I toyed with the umount command a bit more. Nothing worked. Eventually, I came across someone on a Discord server who gave me a working example, and made a whole day feel almost worthwhile. I was able to correctly mount my USB drive and edit its actual contents instead of filling a bubble in RAM somewhere to be flushed out when the power goes out.

Sometimes, I don’t even know if something is a general Linux question. My file system has both sda and sda1 as valid directories to look through, even though I have an sdb1 and so on, but no plain sdb, or a plain sdc when I plug a thumb drive in. This one, I don’t know for sure yet, but I think it has something to do with a bad bootcode, where I referenced sda. Now it’s in my fstab (file system table) file and it shows up every time I boot.

Things are all messed up. I just need to nuke it and start over.

Final question: Working with Micro Core has been fun so far, in the same way a video game can be fun, even if it’s super difficult, provided the rules stay the same the whole time. I can constantly feel success in my fingertips, only for the next challenge to pop up over the horizon. Have you ever applied skills you learned while at play in a more serious situation?

Privacy Policy