Category: MineCraft

Posted on

Minecraft Server Graduation

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am reviewing the history of the Minecraft server my family started for us and a couple friends. Let’s get started!

It all started when we left a larger community when its figurehead started appealing towards a different audience and the culture shifted a little too far for comfort. My sister assembled a series of datapacks from the Hermitcraft server that would give a Vanilla feel to the game while adding a few fun things, resulting in the “Creepers and Cream” pack.

Using a few old parts, I spent a few intense weeks working on Micro Core Linux, trying to optimize every last drop of performance out of the aged CPU. In that time, the biggest takeaway I had was learning the root directory, /. In the end, Java did not want to work for me, so I capitulated and used a ready made distro, MineOS.

MineOS is a Linux distribution that was built to host Minecraft. All overhead is trimmed down, and the firewall is sealed tight, only opening ports absolutely vital for operation: Port 22 for SSH, Port 25565 as the default Minecraft port, Port 8443 for HTTPS access to the WebUI. While I wasn’t too sure about this WebUI and how much it would cut into the precious resources of the host machine, I will say it has been worth it.

One of the early optimizations was adding G1GC to the Java arguments. On the default Java garbage collection, Minecraft would just keep carving out more and more RAM and try to clean it out all at once — literally the worst case possible for a game where things are constantly being loaded and unloaded all the time. I added all the RAM I had and still had laying around and I still had a predictable big crash after a couple weeks of nonstop play.

Things were largely smooth after that. I set up automatic daily restore points and weekly archives. We ended up investing in a 1TB drive when the archives filled it up and the server declined to continue running. My laptop’s Windows drive was formatted in the crossfire.

Over time, our community grew. We aren’t a huge server, but we have a few regulars. The limiting factor I cannot control is the CPU. It has four cores, but get just two people on there in different parts of the map and it maxes out the activity for a single core, and the server starts skipping ticks every so often. It’s still very playable, but I’d like to not see that message, if possible. There are three other threads, but Minecraft servers are still unable to use more than one core at a time. So that is our limiting factor…

At least it was, until people started having random connection issues. It looks like our ISP has seen fit to make things easier for the general public, which is fine, as long as you don’t alienate your power users. Long story short, they’ve moved things around and made their online protection more aggressive, labeling at least one of our players’ IP addresses as malicious. We told it to allow access, and it only gave him a month. I tried looking into port forwarding, and it was elsewhere in a place I couldn’t find. Tech support was no help because the line dropped during a hold and nobody ever called back.

In the face of these challenges outside our control, we are now considering moving to a hosting service. We don’t know which one yet, or when we will move over, but in the meantime, I’m trying to open a creative world on the same machine. The first server rarely uses more than 4GB of RAM anymore, and there are still three other cores, though I will be saving at least one for normal operations and miscellaneous overhead.

Final Question: If you play Minecraft, what version did you start playing on?

Posted on

ButtonMash Upgrade Take II

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am actually doing a one-and-done project. Granted it’s more of a follow up to a huge project I did last year, but still, it felt great getting something short in. Let’s get started!

My family and a few online friends have enjoyed ButtonMash, a Minecraft server I assembled from hardware I had laying around, for several months now, and it recently ran out of hard drive space. Turns out 60 Gb of space doesn’t last all that long when you’re making full weekly backups of the whole server! I started covering this upgrade when I accidentally formatted my Windows drive on my laptop.

I started with a new download of MineOS. I formatted the correct drive and used the dd command to write the image file to the correct drive. With a new install media, I brought it and the new 1 Tb SSD to my tower and hooked them up to be the only things connected. Installation went smoothly until MineOS didn’t recognize the USB WiFi adapter I have.

I put the project down for a while while until I had a chance to continue working on it using an Ethernet connection. The only SATA port my laptop has is hidden below about twenty to thirty screws, the ButtonMash server wasn’t going down for any longer than I could help. Aside from two computers I highly doubted I could use, I was left with the one I put together for my father. With his permission, I installed the drive and ran the security updates recommended earlier during setup.

The only real snag I hit was when I ran into the DHCP configuration requiring manual intervention each time the machine booted. Annoying, as I was working with it mostly from SSH. I knew I had had this issue before, but I couldn’t remember how I solved it. I was a little frustrated with the lack of information online on this topic, but it was amusing for a previous blog post to show up in my search results — twice. My father ended up manually configuring a static IP one boot. It took another hour or two before I remembered static IP was the way to go. I added “fixing the static IP” as something to do announcing project completion.

Copying over the server files was fun. I got into the old server’s web interface and made a fresh archive. Then, using the new install of MineOS, I SSH’ed into the old one to copy the archive over to an import folder using scp. I goofed on the long file path, so I ended up copying it to the home directory and then over to the new hard drive.

With that, I moved over to the new server’s web interface and imported the server. Everything was there, except any backups. I logged into Minecraft and got in no problem, and when I checked, the automatic updates were still around. I’m thinking about redoing those as monthly, but it works for now, nobody touch it!

As a side note, I did some digging into using Let’s Encrypt with MineOS. A thread on the MineOS forums filled in some gaps in my understanding of MineOS’s https security heigine. Https relies on a security certificate –usually issued by a trusted third party– to scramble their communication. When the server self-signs a certificate, you as a client have to trust a potential unknown with keeping their half of the code safe. Before, I was under the impression there wasn’t any sort of security certificate without Let’s Encrypt. However, since the only people who need encrypted access are admins looking to access the web interface, they should probably be in a position to trust a self-signed certificate. From an outside attacker’s point of view, it looks the same as one from a more official source.

I shut both computers down and moved the hard drives around. My father’s computer was reassembled, and ButtonMash’s small MineOS SSD and Ubuntu hard disk were pulled and replaced with the new SSD. I booted it up, logged in with SSH (Public/private key authentication is so nice!), and fixed the static IP from when it had adopted my father’s computer’s IP as static. One more reboot later, and the server was officially up. Within half an hour, one of our players from the outside was on.

One more side note: it looks like by default, you have to first ssh in as a standard user, mc by default, and then use the su (substitute user) command to switch to the root account, as sudo does not come with MineOS by default.

On a finishing thought, I honestly hope someone finds this useful, even if I end up rambling. I purposefully added some key words I wish I had covered last time, so maybe I’ll come across this one next time I find myself setting up MineOS.

Final Question: Have you ever searched for help, only to be redirected back to yourself?

Posted on

Minecraft Server Optimization Part 1: G1GC

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am working on my Minecraft server. Let’s get started!

A few months back, my sister put together a server idea she called Creepers ‘n’ Cream. It runs on Vanilla Minecraft, but has a few datapacks that offer us little gameplay changes, like mob and player heads, Elytra drop on a rematch with the dragon, and a tool for rotating some blocks in place. All I know is that she got the idea from Hermitcraft, a well known Minecraft server for YouTubers and streamers. We don’t run all of their packs.

I covered my process to get the server machine ready to host Creepers. it provided me with about six weeks of content, and in the end, I accepted MineOS as a much easier alternative to a practically custom-built Linux distro.

Once I got MineOS behaving with 16 GB of RAM open to it, I set it aside for a while. At one point, it had been running more or less stably for about two weeks without a reset when a couple players showed up unannounced. We had them contained in a house in adventure mode, so they were more or less contained. The server crashed unceremonially by a game tick (normally 1/20 of a second) lasting for a full minute. After a peek into the accounts’ history, it looked like they were hackers.

I don’t remember the second big crash all that well, but a couple weeks ago, it crashed the same way for a third time. I started doing some research, and found several places talking about garbage collection.

For the non-programmer, there’s a part of a program’s memory called the heap. If the heap ever overflows, the program crashes. As the program runs, objects are put into the heap when needed, and when they aren’t useful anymore, the program marks them as garbage. Every so often, a garbage collector comes by and tidies the heap up so it has more room for new objects. This takes time away from the program you want to be running. By default, Java collects all the garbage when the heap is full. Unfortunately for Minecraft, this causes a noticeable lag spike when garbage collection (GC) happens, and the bigger the heap, the longer it has to wait.

A number of posts I found in my research sung the praises of G1GC (Generation 1 Garbage Collection) for use with Minecraft. From what I gathered, G1GC focuses on making sure unused objects don’t clutter your heap for any longer than necessary. By having the collector come by frequently, it can collect in several short bursts too fast to notice at the trade off of taking a little longer overall.

Somewhere, I read a G1GC guide or two that suggested allocating all your RAM to Java when you start the program. Bad advice for default GC. The server was running a lot worse for a week before I reigned the minimum from 15 GB back to 4 GB.

Farther research into this theory led me to a programming Discord. Someone there informed me I almost certainly had a memory leak. On a trip to Third Workshop, I learned that even though two or more programs may be free from memory leaks their collaboration may introduce them.

I eventually switched over to basic G1GC. Where default GC would require daily restarts to remain in peak performance, G1GC kept the server stable for three days until planned maintenance took it offline.

In conclusion, I recommend all Minecraft server operators consider trying G1GC.

Final Question: Have you ever broke something by following poorly understood advice?

Posted on

Minecraft Server Optimization Part 0: A brief history

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am turning my attention back to the Minecraft server I’m trying to hold together. Let’s get started!

Quick Recap: I delved deep into MicroCore Linux, learned a ton about Linux’s underbelly, then moved on to MineOS to host my server on a computer I’ve named ButtonMash.

I have run Minecraft server software for years — almost as long as I’ve been playing Minecraft. Ever since I saw the Last Airbender plugin for Bukkit back in 1.6. All you had to do back then was download the Bukkit server jar, put your plugins in the right folder, and copy some text in a batch file you run. If you want to invite friends over for a visit, you need to open a port on the router, or ask your admin to do so.

Depending on the plugin or plugins, configuration could be a challenge. I already knew a thing or two about in-game command lines from playing a Sonic fan game I played previously, so it wasn’t that new of a concept at the time.

My entry-level skill set for Minecraft servers was rounded out when I learned to update. Modded servers need time to update after the official release, so I learned how to fix my launcher settings to the correct version early on. I learned how to edit the startup file so it actually works, and that was enough to get me going for a while.

Even back then, knowing what went into making a simple wold made me appreciate how more elaborate servers were set up. I spent a while on someone else’s server, where things didn’t go completely smoothly. There was a childish griefer who possibly had his real name for his account, and an overagressive profanity filter was blocking perfectly innocent words that come up on a daily basis both in-game and on a university campus.

A world or two and a couple family members with accounts later, I furthered my craft some more. I remember running a family server on quad witch hut seed in a then-new amplified terrain world. We dropped the Airbender plugin for this one over an infestation of cactus blocks spawning at the same spot in every chunk just above sea level. We kept the seed, but when an update expanded witch huts’ bounding box, I got in there and manually updated the NBT data on our old huts.

At some point, I got my father playing as well. One family server I think he was on, I learned a painful lesson about backing up. We had a nice, little cove we were all building in. I made a note to backup the whole server in the morning. Someone found our IP in the night. He followed our nether tunnel from spawn to our cove, then raided our stash of gunpowder and sand. The damage from his TNT spree was too much to bounce back from, even with creative mode to speed repairs. The next server, we started using spectator mode to contain new players until an OP can let them out.

Another tool I learned as a more journeyman server sysadmin was Spigot. After Bukkit was shut down, Spigot became the go-to unofficial server provider. The only catch: You needed to follow some more dark, spooky instructions to get your .jar file by compiling it. The hard part is setting it up the first time. There are a lot of steps, and a brand new server operator won’t know if anything is working until they get their working .jar file out the other end. Updating? Good luck remembering where to start in that textbook of an instruction list, because most of them only need to happen once!

This server is getting me to push my Minecraft server sysadmin skills to the next level. Somewhere in my history, I learned how to allocate more RAM to improve server performance, but with more friends frequenting than just immediate family members, I want to make this experience the best I can offer. One of the biggest possible improvements a sysadmin can do is to leave the host machine alone. At that point, you need to start thinking about hardware and operating system, and up to this point, it should be fairly easy for an aspiring sysadmin to grow their trade without crossing their skills over with related fields. Tutorials abound for focused subjects, and one can look up a subject and gain knowledge. Not so, for me anymore.

It feels like I’m crossing some kind of invisible line — or a spread out boundary — where I have been following the footsteps of well-known trails so far, but I have come to a path less followed. People can only write tutorials about their experiences, and as you advance in a field of study, you pass up many of the people you’ve learned from.

While I am not blazing entirely new trails here, I am feeling a little starved for variety of people to choose instruction from. My only guess is that most people who make it this far have either moved on to other pursuits, or are tending their own servers, some of which are monetized through dues or donations. All I want right now is to run my server as smoothly as possible, and I’m going to need to learn a lot more to succeed.

Final Question: What are some stories you’ve gotten over the years while honing your trade?

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 2: Installing Micro Core Linux

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I’m continuing work on a server that can take a bit better care of itself. Let’s get started!

Installing Micro Core was a whole unexpected challenge. I learned how to use a few of the boot options, but actually installing? The drive needed to be formatted, no doubt. I eventually gave in and turned to Ubuntu to format the drive. Doing my research, I went with ext4. I later found it was one of the top picks for SSD, but one of the worse ones for USB drives. I won’t pretend to fully understand it well enough to explain, but I think it has something to do with SSD having a limited number of read and write cycles per sector of the disk. The wrong format can overuse one part of the disk and wear it out prematurely.

Since I was booting from a USB drive, the installer I downloaded was having trouble finding the files to install — it may also be because the OS boots so fast, it doesn’t have time to wake up again after copying to RAM. I tried several approaches, including putting a separate disk image on the thumb drive and and failing to locate its path until I just told it to download the install files from the (N)et. Small joke was on me when Micro Core wanted to format its destination drive again.

While I was doing that, I took another look at just how much space I’d actually need, and an archive of several past servers was only 7GB. I removed the HDD with Ubuntu from any plans for this server and possibly onto another future project I’m not ready to announce.

Trying to learn Micro Core is like trying to learn Linux all over again. Imagine visiting a colony, be it a historic colony in the Americas or a futuristic colony on another planet. Each distro would be like a different family. Some distros are closely related so as to be in the same extended family, while others barely ever see each other in town hall meetings. Tiny Core, and by extension, Micro Core Linux feel like they’re across the town from members of the Debian and Ubuntu family I’ve previously met. While the file system feels similar, the shell and default text editor paint a completely unfamiliar face to look at. (Later edit: the Tiny Core family is a fork of a distro known as DSL, which is a fork of Debian, so the more I get to know the distro, the more familiar things show up.)

To date, I’m only familiar with the Bash shell and Nano text editor. Both provide a relatively open and friendly user experience for anyone not afraid of the command line. The Tiny Core family did not build its command line for people afraid of a text interface. With size and speed as priorities, ease of use isn’t given as much priority. The Ash shell is faster and slimmer, while Vim text editor provides a lot more customization opportunities.

Vim scares me. I had to spend hours just trying to figure out how to move around, and now, the only thing making me even consider keeping it around is the difficulty of adding Nano in.

Apt is the usual way you download programs in Linux setups I’m familiar with. Tce is its less well-known counterpart I have to work with. I’m having trouble learning it, likely because I’m looking first online and only looking through the PDF that came with that documents Tiny Core. It also doesn’t help that most TCL documentation seems to assume you’re working with a GUI.

Insuring Nano was properly installed was tough. I spent a whole evening trying to problem solve, thinking my install was corrupt. The best I could figure out was that I had installed Nano while booted to a thumb drive, but it saved to a different place. When I tried to fix it, tce told me Nano was already downloaded and installed while it was unavailable on the command line. A total of three drives were involved, including my first Linux project running Ubuntu MATE.

I tried bailing, but my attempt to wipe Micro Core failed due to the drive being mounted. I wasn’t able to “umount” it (note the lack of the expected first n in umount; that alone took me between half and a full hour to get). And here lies one of IT’s more haunting nightmares: things working when they reasonably shouldn’t. I came down before bed for a last shot at solving a possibly corrupted path somewhere, and Nano decided to work without either the Ubuntu HDD or the installation thumb drive. Nano has since been stable.

SSH is the next step, but I took a little cut in line for Java. I learned a lot during this period. Working with Micro Core, and I’d assume Tiny Core too, is all about managing persistent files. The OS is small enough to get away with basically reinstalling each time, so unless you protect your data, everything is effectively a temporary file. With that said, I doubt I’ll fully understand what all is where until I finish a second or third project. For all I know, this was just a case of Micro Core repairing itself.

From what I can tell, MCL is one of the few distros to ship without a SSH client. I’ll be using OpenSSH. After a full day of slow learning, I followed a list of directions, somewhat following what was supposed to be going on, only to mess up on the last one and have to start all over again. It went a bit faster this time, and I understood even more of what I was looking at.

Moving along into the final stretch of this week’s planned scheduled progress, I’ve downloaded the Minecraft 1.14.4 server file. Let me tell you: the world is not friendly to CLI denizens (denizen: person living in a place they are not a citizen). I had to search hard for how to download anything, and when I found a couple old blog pages pointing me to a little program called wget. They each provided an old URL that no longer works, even if you update the MC version numbers. The official server download page includes a 40 digit number in hexidecimal.

And here, I admit to cheating a tiny, little bit. After failing to manually copy the URL, I turned to my work on bringing SSH online. A quick paste, which for some reason works with a secondary mouse click to a PuTTY window, and the correct URL was woven into the command.

I realized I had only downloaded the Java installer. I spent the day trying to unpack the HTML for the download page as if it were the actual compressed Java tarball. The shell script I found directed me to a URL, and I thought that was the actual URL to plug into wget. The -O option I used robbed me of a vital clue by overwriting the file name and extension. Something worked, and I didn’t realize it was the wrong thing until I used Nano and read the code for myself.

I wasn’t too sure where to stash Java to make it go, so I put it in with the extensions so it wouldn’t disappear while rebooting. I don’t know what happened after that. I ended up with too many symbolic links between files, likely from recursion somewhere. A reboot broke Java. Things are just a little too messy now. I don’t know what’s what anymore. This job isn’t over.

Final Question: Have you ever gone out looking for instructions while the answer was there in front of you all along in manual form?

Posted on

New Priority: Minecraft Server

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I’m setting up another Minecraft server, but this time, I’m setting goals a bit higher than usual. Let’s get started!

I am after an automated, headless, dedicated Minecraft server. That means I want a machine that only runs Minecraft, and nothing else. The machine itself will live in a network closet or somewhere where it can have a power cord and Ethernet while I use SSH to get in to change things. I don’t want to have to babysit it, so I want to write a script or two to manage the whole server. The whole idea is to get the maximum amount of performance for Minecraft while spending as little as possible on the OS and other supporting software.

The main bottleneck is RAM. I have 8 GB to work with for now, and that’s fine for running a survival world and a creative world at the same time in Ubuntu, plus a couple tabs in a browser. Both this machine and Derpy have historically been used to host Minecraft servers, but I want to consolidate any running servers into a single machine. To that end, I’d like to see if I can comfortably run three or four servers at once.

Distribution choice is a little more important now. I’m after something as light weight as possible. Unlike the past several months, I’m actually doing progress reports as I go, so I don’t actually know what I’ll have when I’m done. I’m seriously looking at about six distros ranging from Ubuntu Server to Lubuntu to Puppy Linux.

A family Minecraft friend who will likely be playing on the server brought up Linux From Scratch. It’s a resource for compiling your very own distro. It looks fun; it looks educational. I looked up a couple video reviews of it and decided it looks one or two years down the line for me. My goal is two weeks here, and hardware challenges are starting to make me think I may already need to double that.

It turns out there are a bunch of tools for people who want a little more involvement with what’s in their operating system without wanting to go into source code level of detail. All the ones I looked at either have their domains up for grabs or are otherwise obsolete.

There was one more distro this friend brought up: Tiny Core Linux. It aims to provide you with only what you need to get started with a wide variety of projects. To paraphrase their stated goal: add what you need, not demolish what you didn’t ask for. After poking around a bit more, I found another version on their site that nixes the GUI. It’s not like I even wanted one for this project anyway. Micro Core it is until further notice.

I remembered how Derpy used to have this SSD it supposedly used to improve make things go faster. It’s not like it was being used, so I thought maybe I could use it as part of my little project. So I opened Derpy up and pulled it out.

Different computers with open architecture have different schemes of making sure everything stays where it’s supposed to. When I installed Derpy’s present SSD, I didn’t have the correct part to mount it on, so I just put it on what I had and let it be. With the HDD to SSD bracket being freed up, I went ahead and swapped things around. It just took a while to figure out how to get the bracket off.

With the brackets finally swapped, I moved Derpy’s old 60 GB drive to my project computer case and connected it with a SATA cable I had laying around. I think it may even be the one it originally came with. Power was similarly available within the case, but I had to remount the SSD to another position within its bracket so it could reach.

Trying to mount Derpy’s SSD with Puppy Linux

Backing up a little, before I started seriously considering Micro Core, I burned a Puppy Linux live CD. Puppy Linux is another one of those small distros that comfortably loads into RAM.

It’s funny how the sound of a CD drive made me smile. It used to be the sound occupying the boring period between when I started computer time, and when I started actually playing.

I rejected Puppy Linux after I saw office software as well as other stuff I didn’t need included, like a whole GUI environment. Nevertheless, I still used it to verify that I had everything hooked up correctly. It took a while, but I happened across a utility within Puppy that left no doubt. I spent a while trying to see if there’s anything on the drive before I eventually asked my father and he went ahead and told me to just format it.

I know I said I was going to do a more update-style post, but this is running into a longer entry, so I want to split this one. It provides a natural-ish breaking point about here. While I thought I was going to need about two weeks, as of this writing, I’m thinking either three or four weeks total work may be in order. If I break things up like this, I may end up with even more parts. That, or I just spend some of those weeks not doing much but learning what to do next.

Final Question: Have you ever messed around with otherwise junk to turn it into treasure?

Privacy Policy