Month: June 2020

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

My First Online Scam

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am telling the story of my first experience with a 419 scam. Let’s get started.

I’m writing this during a time of many projects, and if this post appears randomly, it probably means I need a week off, or I’m stuck and need extra time with next week’s project. Even now, it’s been a few weeks, so parts are already slipping away.

It all started when I received a computer related Discord message announcing a giveaway to help with the hard times of the pandemic going around. I had won .81 bitcoin! Huzza! How much was a bitcoin worth? I looked it up, and it was floating around the $9200 mark. I was staring down about $7000 if I could go claim it. The message gave me a code and a link to a cryptocurrency exchange where I could redeem it.

I was suspicious, as I should have been. Red Flag 1: I never entered any giveaway. Red Flag 2: The account giving away this freebee had only just now joined the only server we had in common. I decided to check out the link, but not as myself just yet. I decided to install TOR browser to make it look like I was somewhere else. One problem: Debian’s repositories only allow old, proven software. That’s when I learned about backports.

According to the Backports page on the Debian Wiki, “Backports are recompiled packages from testing (mostly) and unstable (in a few cases only, e.g. security updates), so they will run without new libraries (wherever it is possible) on a stable Debian distribution.” It goes on to say you should only use what you need without using every backport in the whole of Creation, at which point, I’d think you’re better off using the testing version of Debian Sid, the “unstable” version.

TOR went on without too many additional problems. I followed the link, and the site looked professional enough. I revisited it with regular, old Firefox and made myself an account using a unique password, as you should. Red flag 3: I didn’t get a notification e-mail. I noted it, but chose to ignore it for the time being. The site also went out of its way to point out that it was using https for encrypted login.

Redeeming the code went smoothly as you’d expect. I figured there’s no point in spending the money until I had gotten something tangible off this exchange. I mean, $7500 or so is enough for a very nice desktop computer — maybe even a couple just nice ones, even after paying a 10% tithe to my church. I even contacted their online giving section and was a little sad they didn’t accept Bitcoin. The most impressive part of the exchange was how it was already Friday afternoon, and they still got back within about four minutes.

I decided to try making a small purchase, but there was a small matter of the exchange saying there would be an equivalent of a flat, $5 charge for every transaction. Yellow Flag: While this business model is entirely reasonable, it discourages testing them out with small payments. It’s easier to ignore $1000 +$5 than it is to ignore $1 +$5. Switching things around, I found a way to purchase from NewEgg using a service that accepts Bitcoin and decided it would be good to pick out some hard disks for a future project.

In parallel with that project, I learned a bit more about the mechanics of Bitcoin payments. I tried making an anonymous account on a more reputable cryptocurrency exchange, but they wanted personally identifiable information. Red Flag 4: This other site I was working with was only 3 days old, according to domain name records, yet it had articles dated before that.

Another tidbit I learned from a third party was that there are laws forbidding cryptocurrency exchanges from making cash payments until the account has already received payment from a verified bank account, and then it can only pay to that bank account. Turns out that’s to prevent money laundering.

I continued on with trying to buy the hard disks by moving the Bitcoin off the exchange and onto my phone. I generated a code, moved it over to the exchange, and… Error: new account, please deposit about $200 to unlock your account. Bummer! I had been warned about this, but I chose to go learn about it anyway.

A sliver of faint hope was finally dismantled when I talked with one of the mods on the Discord I was on. Turns out multiple people had gotten targeted, but I was the first to report this particular individual. After a screenshot of the PM he sent, he was banned from the server.

Final Question: Have you ever been targeted by a 419 scam and come out the other side with an interesting story?

Posted on

“Beowulf Cluster:” Part 5: DHCP and NAT

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I am getting a head start on this post, so I don’t yet know where the end point for this segments. Let’s get started!

I hate networking. This router project is really taking a lot to learn. I’m losing track in my memory about what point I was on when the official break in weeks happened. Right now, I’m just looking forward to the time when I can say I have a custom router, and setting up the “Beowulf Cluster” I originally set out to build –not that I can really call it that anymore– should be one more week™ after that.

Once I had the network interfaces set up correctly, DHCP wasn’t far behind. I had a few semicolons missing after some lines, but that was about it. I plugged my laptop into the my little subnet and the Pi assigned it an IP in the range I had told it to. It just wouldn’t let me at the Internet at large, even though I haven’t changed iptables off its default of accepting everything yet. Of note: I was unable to use the Internet even while still connected wirelessly. Two weeks ago (Was it only that short ago?) I would have just poked around with “black box reasoning” before concluding that Ethernet superseded Wi-Fi because it is faster, all other factors being equal.

Further investigation led to believe I should look into NAT (Network Address Translation). It’s disabled by default, likely because if you need it, you’ll soon learn about it like I’m doing now.

A couple guides later, and I had uncommented a line in a config file to allow IP forwarding, but when I used modprobe ip_forward to add NAT abilities to the kernel, listing out my iptables gave a warning about legacy software.

***

Well, this write up is coming due, so here’s what I’ve got.

I worked with a couple friends on my private Minecraft server –yes the one I’ve covered here before– by the names of doflagie and TheRSC. We didn’t go messing around with NAT tables, but we did inspect the DHCP configuration files some more.

At least, that was the plan at first. I accidentally broke an interface by editing the file there. Rebooting cut off my connection. I SSH’ed in over the other interface and promptly broke that one too. I had to swap around cables to fix those config files, so it was all good.

With my little review from last week out of the way, I went to weed through the actual DHCP config file. I wasn’t sure where it was, but before I resorted to finding it again online, I noticed one terminal on my workstation was already in a local DHCP directory when it wasn’t SSH’ed into somewhere else.

As part of my workflow, I hooked BlinkyPie up to the Ethernet subnet. Thanks to the default Raspian settings, eth0 overrode wlan0 as the default network interface, so I didn’t have to disable or disconnect Wi-Fi. Otherwise, Blinky is standing in for a generic microcomputer on this micronetwork.

It took several hours, but when I rearranged the DHCP config on the Pi4 to reflect the subnet and not the wider home network, I was able to reach out from Blinky through the Pi4. However, I was only allowed to the gateway, and no farther.

These results are underwhelming. Each last problem feels like it is comprised of a chain of smaller problems, leading to another such chain. I’m making progress, but if feels like the goalpost is moving on me.

Final question: How hard should this really be? Sure, there are higher lever programs, but how long should a low-level approach like what I’m doing take to figure out?

Posted on

“Beowulf Cluster:” Part 4: Network Interface Connections

Good Morning from my Robotics Lab! This is Shadow_8472 and today, I am working on that Pi4 network piece again. Let’s get started!

I am having the hardest time with networking. What could have been a confusing, possibly straightforward black box operation turned into a subject of study where I’m likely going to be able to do my own thing later on. With that better foundation, I just might add DHCP back in into my general plan, as such a system would be a much more useful tool I could use in an upcoming project I’ve been looking forward to.

As stated in an earlier post, I’ve been cobbling my way together using a series of incomplete tutorials and seeking help understanding the gaps. Many video tutorials for networking are either old, made with bad audio quality, have a presenter with a thick accent I can’t make out, or a combination of the three. Text is unfortunately the way to go.

My functional goal for this week was to get the Pi 4 functioning normally online with a static IP. Through whatever mishmash of tutorials, the following is what I’ve cobbled together as I understand it.

The Pi 4 has two network interfaces, one called eth0 and another called wlan0. These names represent an old standard on the way out, but for this week at least, I’m sticking with them. I started by going to /etc/network/interfaces and set it up so each interface has its own configuration file in the directory /etc/network/interfaces.d/. Eth0 was straightforward to set to static, but wlan0 had another pointer elsewhere for the WiFi name and passkey.

My first big problem was in how I had to copy configuration file examples by hand. At my worst point, I had some equal signs where spaces belonged and spaces where underscores belonged. The former was a mistake I made when looking at two related, but dissimilar files, and I diagnosed it by paying attention to the error messages when I tried sending sudo ifup wlan0.

The later was a mistake I made because I was copying things by hand without SSH and a dark mode plugin I use actually cut off the bottom row of each line of test in a code box, including the entirety of each underscore. This one only told me the interface failed to start. Someone going by Arch on the EngineerMan Discord pointed me to journalctl, some sort of log viewing utility. I piped the wall of text through grep to pick up wpa_supplicant, a utility that kept complaining. Journalctl also pointed out locations of errors with quotes around the WiFi SSID and psk fields where I needed strings.

Assorted errors along the way included a mistaken time zone that was easily taken care of. I also had a surprise when the contents of /etc/wpa_supplicant/wpa_supplicant.conf vanished on a reboot: turns out I had a blank copy in /boot and as Raspbian boots, it will move certain configuration files in that folder around to overwrite their permanent counterparts, leaving me guessing as to what’s already been done.

With stable network interfaces, I started testing them, but I wasn’t able to ping anywhere successfully. I noticed that it was using its IP from the eth0 socket, and not wlan0 for some reason. Eventually, I either found or was directed to route or route -n: basically the table where Linux decides what door to send packets out of as they leave. Eth0 was set up as default if no other matches on the table were found; all my ping packets were being sent inward and getting lost instead of getting sent out, into the wild.

I spent time studying this new table and found a clear, black box style tutorial I was able to reverse engineer LINK. Manipulating the table directly was straightforward enough, but what I failed to realize was that parts of the table are generated fresh each time a network interface goes down or comes up. My work totally collapsed when I rebooted, reverting the default interface back from wlan0 to eth0.

The fix (shown as “Part 2” in the black box tutorial linked above) led me back around to the beginning. Part of the configuration of different interfaces includes a setting called gateway. I actually had to move it from eth0’s config file over to wlan0’s config file.

Admittedly, I am a bit disappointed in this week’s results, but I learned a lot more than a total black box experience would have afforded me.

Final Question: Have you ever poked at a “black box” and learned how it worked?

Posted on

Family Photo Chest Part 7: How to Plug In a Scanner

Good Morning from my Robotics Lab! This is Shadow_8472, and today, I would like to share with you the inSANE time I had trying to set up a scanner without root privileges. Let’s get started!

SANE is a resource for Linux to streamline the setup of scanners. From what I understand, it’s supposed to just make things easy.

Unfortunately, there’s a bug (or was) a bug in the version written for Debian Buster. I honestly thought this would be easy; I spent the whole week trying to not only fix the issue, but understand what I was doing as I was doing it. Special thanks go to all the people who at least tried to help me on the various Discord servers I broadcast my distress calls on.

As with any problem, diagnosis is the first step. Tutorials, in general, expect a clean installation, but I’m past that point. I’ve already tried, and failed to complete this procedure. I at least know how to look around with ls -l and other commands.

I started out with sane-find-scanner and lsusb, and eventually figured that while I –my user account– had permission to use the scanner, I didn’t have permission to access the USB bus it was connected to. A little research led me down the path of exploring the groups mechanic of Linux. They appear very useful, but I have yet to figure them out. What I did learn was that the scanner group wasn’t enough to let me scan in and of itself.

It took me a while to find that bug, but since it was crossed out and a note said it was fixed in some future build, I updated everything from the apt repository and nothing! Reboot: nothing!

I reexplained my support issue several times across multiple Discord servers, and I sometimes got someone to try and help me, but eventually, I ended up going back to that bug and reading up on it.

Buried within what felt like an endless amount of terminal output with the occasional e-mail header, I came across a workaround. It called for making a symbolic link between a couple files, then to put some text in a file elsewhere in the filesystem. The instructions sounded familiar from my last attempt, and they were consistent with other Linux help forum posts from different places.

I spent about a day trying to figure out why the symbolic link wasn’t showing up. The folder in question where I thought it was supposed to appear already a link. There were three files in the directory, and when I used a –verbose flag, I saw three entries. I rummaged around in ln –help and found that one of the other flags caused links to overwrite existing links to replace them. I figured that must be happening here, but its timestamps weren’t changing from a date last year when I supposedly updated them.

I eventually decided to play around with a symbolic link in an isolated spot in my home directory. I had my sandbox directory with another directory in it. I made a test .txt file in the sub directory, and tried making a link directly in the sandbox’s root using the same flags as in my problem link. The link didn’t appear in the root, but it instead replaced the text file, and the terminal warned me about it being a broken link by rendering the link in red instead of the normal cyan. I fiddled around with it some more by remaking the test .txt file in the root and leaving the link in the sub directory. I had a few missteps, but I managed to access the file by using the link.

Back on the main area, I found the links I had been overwriting in the other directory by listing them with ls -l and scanning for a timestamp that wasn’t in 2019. Three entries popped out at me. On closer inspection, the link I thought was a rewrite dud was, in fact, linking to a file within the same directory, but with a different name. It looked like it was meant to catch programs calling for the old version of a program and redirecting them to a slightly updated copy — just like forwarding mail.

The rest of the workaround was simple. I learned about the touch command, a little program to update a file’s timestamp or create a file if it isn’t there. I rebooted and had a good feeling when I heard the scanner move a little as Linux was starting up. Sure enough, I was able to start the GUI interface without superuser.

All in all, this week taught me a near-miss lesson about one of the more interesting features in Linux, and apparently Windows as well.

Final Question: Who’s ready to hook up a printer?

Privacy Policy