On why your childhood is not ruined

Kenner collectible Rancor Toy from 1983, two years after I was born.

Let me start off by saying how thrilled I am to have all the new fans in the Star Wars fandom. Welcome to an obsession with a fictional space that has thrilled many of us since before we were old enough to be aware of the toys we were playing with from yard sales (yes, I had a Rancor and Luke Skywalker before I had even seen the movies, which made them all that much more magical for me.) There’s nothing quite as thrilling as being able to share an affinity for something you’ve loved for a long time with a new group of friends you never expected to be interested in it. There’s also a risk to it, however, because those new friends might not find the same value in the thing as you did.

By Source, Fair use, Link

When I was in college, a buddy of mine went to see “The Scorpion King” starring with Dwayne Johnson still being billed as The Rock. This was the perfect intersection of his interests, as a life long fan of wrestling (he explained it as a soap opera for men) and as a sequel for one of our group favorite movies in The Mummy movies, he was sold. So much so that he went to see it before any of the rest of us in our friend group. He hated it. So much so, that he convinced the rest of us not to see it.

A year or so later, we all decided to watch the worst movies we’d ever seen and do a Mystery Science Theater 3K treatment on them. After commenting our way through another terrible sequel (Jurassic Park 2) and loving it we put this bad boy in and started watching. Within the first 15 minutes we hadn’t made a single comment, but were laughing so hard we could barely breathe. The buddy who’d hated the movie so much stood up and declared loudly, “Screw you guys, if I’d have known I was *supposed* to laugh at this movie so much I’d have loved it!” We had a blast watching it, and it’s a favorite of all of ours now. The gambit with this movie was taking the camp of the original Mummy series to an obvious terminal point, and no one could have done it better than The Rock. My buddy had his faith in his fandoms restored, thankfully, by the presence of new perspective from his friends.

This is the advantage of revising our old fandoms. It’s also the danger. We take these memories out of their pristine boxes, and much like the little crystal balls in Pixar’s Inside Out, we run the risk of breaking them if they are not handled with care. Sometimes the memory is so much better than the actual experience was, and whole pieces of our identity are built around them. To lose them, is certainly to lose vast sums of who we are, especially where they were forced to be niche and kept apart from civilized interaction.

I’ve gone through this cycle more than a few times, I think all of us have. Dungeons & Dragons is a wave I caught as a 10 year old, though it was already nearly 20 years old by the time I picked it up, it still wasn’t mainstream, by any stretch of the imagination, and there were still people calling it Satanistic (like the Harry Potter series even now.) It’s much more mainstream now, and I love reveling in it with people, especially when it hits a big moment like the beautiful treatment the game got on several occasions of Community. I can promise you, the writers have played Dungeons & Dragons, as this is the most accurate series of representations I’ve seen to date of the groups I’ve gamed with.

While I hate to bring up a sore spot, Game of Thrones is another that I was into before it hit the main stream. I’m not at all upset about the directions the TV series has deviated from the books, far from it. I love retellings of stories, and I would be the last to tell you that the book is better than the movie, because they are so completely different in their telling of the same story. What does irk me about GoT, and GRRM is the fact that the last couple of books are not going to be out before the series is finished. I hope they do finally come out, and that we aren’t just left with a series finished inaccurately in TV form to fill in the major questions left at the end of the book series.

The Iron Throne. Courtesy of South By Southwest Festival

And this is where we discover the hazard of a fandom becoming popular, or getting a refresh, or finding a new audience. When the new model overtakes the old one in popularity, interest, or commitment, then us original fans have to take a step back and reevaluate those memories. They sometimes shatter under the new scrutiny, and we hurt, because years of defending our stance on a thing, or being devoted to it, becomes hard to justify when we really look at it, especially to what we see as casual interest from the masses.

I don’t want to justify anyone’s behavior in being denigrating to cast members, or even writers and directors, for their participation in producing new, fairly popular versions of films. Even creators like GRRM and Lucas deserve a pass here, in some regard. The popularity they gather to themselves and their creation makes them nigh unquestionable, and if there is anything you take away from the behind the scenes looks at the original Star Wars trilogy, it’s that Lucas needed those level voices to balance his world building with good character development and storytelling.

This brings us back to Star Wars. Welcome new fans, I’m glad you’re here. I hope you enjoy the lightsaber fights, the sweeping space battles, and the amazing story from a long time ago in a galaxy far, far away. To all you old fans who feel like your childhood is being ruined… enjoy the memories you have, they wouldn’t have been worth any less if the new movies had never been made, so don’t make them worthless because the new movies have been made. If you want to make new memories with the new movies, make them. If not, ignore them and like what you like. The one thing that can’t be taken from you is the experience that made your fandom so awesome to you in the first place. That’s the key. Also, remember, that someone is having the doors opened to this amazing world, and they’ll be able to find the memories, and quality for themselves, and that’s okay, because that’s how you found it as well.

Server Management for Middle Schoolers Part 3: Ease of Use

I may be crazy, but I know there are some Middle Schoolers who can run a server. So I’m teaching them headless shell management and scripting, all so they can play Minecraft (the carrot, in this case.) They are learning surprisingly well, but then, so am I. I’ve never had to create a fully group setting on Linux, and didn’t anticipate all the issues I’d run in to. Wanting to have 17 kids in an ssh group, with access to a games folder that consistently outputs files they can all use, and allows them to run an instance of Minecraft they can all access… It is a lot to figure out. This series is going to cover the settings I came up with.

Bash Script Startup and Ease of Use

The biggest problem that I knew I was going to have dealt with the running of scripts. Most of these kids had never been exposed to a Linux environment, much less actually dealt with a command line. We were secure shelling in, so there wasn’t a GUI for them to learn and play with, but they had dealt with all of that issue like a champ. Some of them were getting taxed on the amount of commands they had to use, so I didn’t want to burn them out.

The tmux script that I was working with basically did three things. It set up the temp folder for the tmux instance, made sure that the group managed it, and then dropped in to the instance to operate it. The problem was the amount of typing each of these commands took. Individually, they look like this:

tmux -S /tmp/tmuxDirectory new-session -d -s Minecraft
chgrp MyGroupName /tmp/tmuxDirectory
tmux -S /tmp/tmuxDirectory attach-session -t Minecraft

which is a lot to remember for newly minted shell users. So I opted for scripts. Fortunately, these things are easy to write, and simple to use when you teach them.

Taking those commands and working them into a new serverstart.sh file looks nearly identical. I just commented what was happening with each line before I wrote it, for clarity, and threw a hash-bang /bin/bash on the top. Then I noticed I might want a little more abstraction, so I altered the file to pull the directory, the session name, and the group (incase it needed to change for some reason) out of this file. They are represented here by the $CONSTANTS

#! /bin/bash

# Import server configuration
source config.sh

# Abstract tmux code start $CONSTANTS in config.sh
tmux -S $DIR new-session -d -s $SESSION

# Change the group setting of the $DIR
chgrp $GROUP $DIR

# Start the server
echo Starting $SESSION Server Now

And at this point using the tmux ability to pass along keys is important.

tmux -S $DIR send-keys “java -Xmx2048M -Xms1024M -jar minecraft.jar nogui” C-m

obviously, even this code could (and should) be abstracted a little bit.

With all of this set, the only command the kids will need to remember to start the server is the executable ‘./startserver.sh’. So make it executable.

chmod +x startserver.sh

Other Useful Bash Scripts

Besides starting the server, there may be a time your team will need to manage the server, or stop it. Here are those scripts

serveraccess.sh

#! /bin/bash

# load the configuration
source config.sh

# Attach to shared server instance
tmux -S $DIR attach-session -t $SESSION

serverstop.sh

#! /bin/bash

# Load the configuration
source config.sh

# Stop the server
echo Stopping $SESSION Server
tmux -S $DIR send-keys “/stop” C-m

# Wait 5, then kill the Session folder
sleep 5
tmux -S $DIR kill-session -t $SESSION

You could, of course, be much nicer in this script and give players time to log out, but the flavor of that is up to you.

Wrap Up

I’ll be writing an update soon to tell about how these lessons have been received, how they are progressing, and some interesting difficulties with this situation that have arisen.

 

Server Management for Middle Schoolers Part 2: The Group Folder

I may be crazy, but I know there are some Middle Schoolers who can run a server. So I’m teaching them headless shell management and scripting, all so they can play Minecraft (the carrot, in this case.) They are learning surprisingly well, but then, so am I. I’ve never had to create a fully group setting on Linux, and didn’t anticipate all the issues I’d run in to. Wanting to have 17 kids in an ssh group, with access to a games folder that consistently outputs files they can all use, and allows them to run an instance of Minecraft they can all access… It is a lot to figure out. This series is going to cover the settings I came up with.

Setting up the Group Folder

The plan here, was to have all the group with ssh access have a united home folder that we could work from for our game instances. The top level folder, and everything underneath it, would need to be accessible to the group, not just to the creator, so I played around with some settings, and came up with a solution that worked.

Setting the Permissions right

The first thing I did was create a ‘games’ folder in the ‘home’ directory. I knew I wanted this folder to be a group folder, so I ran the chgrp command for it:

$ chgrp myGroupName games/

Then, when you run the $ ls -la, you’ll notice that the creator is still listed as your user, but the group is switched to myGroupName. That way everyone in the group will have access to that file. So I copied the Minecraftserver.jar in there and thought that would be it. Since we were planning multiple instances of Minecraft, I also added a folder for this first, vanilla version. The tree looks something like this:

/home/
|-> games/
|-> vanilla_minecraft/
|-> minecraftserver.jar

When I ran the minecraftserver.jar so I could edit the EULA, I noticed a problem. The file (even though I had changed its permissions as well) ran as if all the files were being produced by, and for, just my user. This was a problem. I could go back and change it often enough, but that wouldn’t work for times where I wanted the kids to handle things. I needed the new files to have the same group setting.

Setting the GID on the folder

So I emptied out the ‘vanilla_minecraft’ folder and got ready to try again. I made sure all the files had the right permissions, then did one more step on the ‘games’ folder. I set the GID for the folder. This is a handy trick, because it allows all the files created within the directory to inherit that same level of permission for the group use. Here’s the command:

$ chmod g+s /home/games

to make it apply to all subdirectories as well, simply add the -r flag. This way, whenever any group user runs an executable, any files created will be created with the group permissions of the top folder.

Security Note

This can be a dangerous procedure if you aren’t careful where you apply this type of thinking. It is useful as a shorthand to give a group permission to run files, but you have to be careful what type of files are put in there, and what other things those files touch. I tested it out a couple of times, and was able to create some files in other directories that I didn’t have access to normally because of the group setting. So be careful here, your group needs to know that this is a potential danger on a server, but it’s probably the best balance of security and ease that I was able to strike.

Actually Starting the Server

At this point, I created an open port for the minecraft server, and then ran the server to get the files setup, but that created other problems. I used screen to start the instance the first time, but then realized that we were going to have a problem when the kids tried to attach to that screen, that they weren’t going to be able to. After a bit of searching, I found out that screen wasn’t going to work for what I needed, so I switched over to tmux and found some nifty hackarounds that would work. Namely, creating a specific /tmp folder for the tmux instance and setting its group permissions. This solution, however, was going to be a headache for the kids (it already was taxing me to write out all those commands every time) so I knew what had to be done next. Time for some Bash scripts!

Server Management for Middle Schoolers Part 1: sshd_config

I may be crazy, but I know there are some Middle Schoolers who can run a server. So I’m teaching them headless shell management and scripting, all so they can play Minecraft (the carrot, in this case.) They are learning surprisingly well, but then, so am I. I’ve never had to create a fully group setting on Linux, and didn’t anticipate all the issues I’d run in to. Wanting to have 17 kids in an ssh group, with access to a games folder that consistently outputs files they can all use, and allows them to run an instance of Minecraft they can all access… It is a lot to figure out. This series is going to cover the settings I came up with.

Setting up a good sshd_config

There are some really great settings in the sshd_config script (/etc/ssh/sshd_config) that shouldn’t be overlooked. Options like changing the default port, assigning an approved group, and, optimally, using RSA keys are a must here, at least eventually.

Changing the Default Port

Because I need this server to be secure, it is attached to our school network after all, and because I want a group of lively administrators to have a sandbox to work on, I need a way to lock out unwanted access. The first step, which a student in the group duly noted, is to change the port number away from the default 22. That’s a simple fix, just look for the line and change it:

 # What ports, IPs, and protocols we listen for
Port 22

You can’t pick arbitrarily, but you can assume that most numbers below 1000 will be useful here. Settle on a port that isn’t used by another popular program as a default and you should be okay on traffic issues. Just as a point of reference, I got 2200 hits against Port 22 in the weekend before I could get our network admin to change the routing table to our new Port. They ranged from attempts to login using every possible username from ‘root’ to ‘techhelp’, to attempting to negotiate RSA keys. The saving grace from these attacks was the next step I took.

Setting Up an SSH Group

I’d prefer to use RSA keys for login, but haven’t had a chance to fully explain that process to the students yet, so we’re using passwords for now. Getting away from port 22, which is often attacked by bots as a pre-trial for an actual attack, was the first step. The next step is a bit of an extra measure. I knew I was going to need a group for these kids with special privileges, but I certainly wasn’t about to give them su. Inside the sshd_config there’s a setting to grant ssh privileges to a group of users, you can change it like this:

# Allow only certain UserGroups to access the ssh
AllowGroups myGroupName

This way, all of the random tries for usernames (even for root) will result in a failure, but it won’t tell the attempter why. This also accounts for attempts to attach with an RSA key, so bonus there. Only users in this group will be allowed to remote shell, however, so be sure to add yourself to the group. I speak from experience here.

Creating a Banner for Good Measure

It’s a good idea to also set up a banner for good measure. There should be a commented line in the sshd_config file that looks a bit like this one:

Banner /etc/issue.net

That gets printed out on an attempted login, say someone guesses a name that is in the userGroup approved to remote ssh. This may happen, and this file will, at the very least, show that you are paying attention to details. Most hackers won’t actually care, honestly, but amateurs might get a moment of pause. You can make yours funny for the added measure of giving a potential hacker a chuckle, may save you some time down the line. Currently, mine’s a mix of legal disclaimer, and boring threat. I’m working on something snappy.

Conclusions for SSH Access

This was a good lesson in the config files for ssh for me. I knew about some options, but not others. I think the real gem here is the setup of an allowed group. Keeping in mind that each user typically has their own group in a UNIX setup is a valuable thought for a broader sense of server management, and the idea that you could set multiple allowed groups through this setting is also quite useful. Next time I’ll talk about the Group ID and setting the group bit on a folder so that the whole group can access files and run services that are interoperable.

What My Bike Has Taught Me About White Privilege

I have nothing to add to this. It is very accurate and an experience I share and will cherish as an example.

A Little More Sauce

The phrase “white privilege” is one that rubs a lot of white people the wrong way. It can trigger something in them that shuts down conversation or at least makes them very defensive. (Especially those who grew up relatively less privileged than other folks around them). And I’ve seen more than once where this happens and the next move in the conversation is for the person who brought up white privilege to say, “The reason you’re getting defensive is because you’re feeling the discomfort of having your privilege exposed.”

I’m sure that’s true sometimes. And I’m sure there are a lot of people, white and otherwise, who can attest to a kind of a-ha moment or paradigm shift where they “got” what privilege means and they did realize they had been getting defensive because they were uncomfortable at having their privilege exposed. But I would guess that more often than…

View original post 1,649 more words