My SDBA Bootcamp: Episode 5
I am starting think Node is basically a straitjacket for Javascript….
So TIL that pretty much EVERY file in Node is a module that wraps the file in a function that takes exports, require, module, __filename, and __dirname, (dirname is funny to say out loud — DUUUUURRRRRR. Also shows how I feel). If you have ever touched Node before, you might recognize these. The nice thing is you don’t have to worry about this function and for the most part it doesn’t seem to be your problem. But it is nice to know it is there. We are wrapped in a warm module wrapper blanket that protects us from the fact that Javascript was hacked together in a week and was made for browsers.
SystemDURRRRRRRRRRRRR
So anyway, what were we doing in the previous episode? Oh yeah, wondering why SystemD wanted to D over the kernel.
I am wondering why it was whining about this only when I installed Node…..given that SystemD is an init system. I do recall my friend said that maybe some update got interrupted.
I just remembered the logs are the thing (I think I hear a sys admin facepalming in the distance….). Here is a cool source I used for this part: https://www.cloudbees.com/blog/running-node-js-linux-systemd
(not sponsored — I don’t even know what they are selling.):
So here they say to use journalctl -u. (Has anyone figured out writing code in Medium? It seems you can’t copy and paste it in! So if you are wondering why there are screenshots…..)
I am going to try journalctl -u systemd and see what happens. Since we are just asking for the logs of something, I feel like it is safe to just start trying different services on it. With other commands that I wasn’t so sure about, this may not be a great idea.
Now let’s try systemD@1. The article I posted has the author putting that after Redis (We are definitely not going to mess with Redis yet here).
Same as before.
So do you remember this from earlier?:
These were some that we knew were getting touched somehow (that sounds weird…). So let’s try these and see what happens. It at least will help up learn the journalctl command.
So I tried upower.service, nginx.service, why-no-service, and they all didn’t have logs…..
This is unfortunate. There are logs everywhere though. I looked to see what Linode themselves had to say. There aren’t any logs like in the GUI console Linode gives you, but they do have this article:
I forgot about those logs…..I am not super confident though because I think those only tell you from the start of that session. Don’t know why I think that. So I will try to vim the kern.log.
You need sudo. Figures. Whenever you see that \ in the beginning of a path, you know it’s starting directory you will have to change to is in the root directory.
Well, we really need to move on. This is an issue I will stick a pin in, and come back to. Or if it comes up again, then I at least might be able to get more info. But for now, we need to get this project going and it is already bad enough I am getting out of my post schedule (I hear the internet coming with it’s ruler in hand…). If anybody has any insight, let me know.
Get the thing to talk to the other thing and then do the thing…
So I have worked with projects where there was Node and Nginx, but they were already set up. I haven’t set one up from scratch before. If I recall, I think it is just as simple as letting Nginx know what port to listen on. Nginx is very good for giving you imposter syndrome. I have spent A LOT of time trying to learn Nginx and trying to not think about the fact that my mentors seemed to understand it so flawlessly. I found that (IMAO) a lot of documentation online assumes that you have configured Apache, Nginx’s godparent that it is quickly eclipsing. You have to give yourself time. That being said, I am going to save you some time:
Nginx installs itself in the root directory, and spreads itself out all over the place. This doesn’t make sense if you are pre-mad tech skills because you are used to something being installed in one place, like the applications folder or desktop (if you ever even noticed anything other than the desktop icon. Not judging though, neither did I). But servers are meant to really do one thing — serve websites. Since you are likely to start out in Ubuntu (Tell me I’m wrong), here is where stuff is:
- The main conf file is nginx.conf and is under
/etc/nginx - There is sometimes also a default.conf under
/etc/nginx/conf.d. At least that is what I remember. I didn’t see it in my linode server. By default it just refers to the nginx.conf until you do something else with it anyway. It is more for when you start messing with multiple websites on one server. You’ll get there when you get there - This is where it gets confusing — the files that actually are html files that a user will see when they visit the website is in
/var/www/html - RTFM: http://nginx.org/en/docs/beginners_guide.html
- Then RMOTFM: http://nginx.org/en/docs/
When you are starting out, just worry about the nginx.conf. You will see all these tutorials claiming to be for beginners and then get into the site-available and sites-enabled folders. Nu-uh, that is for when you have multiple websites I am pretty sure. In any case, you only need to mess with the main nginx.conf file for now.
As overwhelming as it can get sometimes, remember that everything nginx can do really is in these directives: http://nginx.org/en/docs/dirindex.html. even then I think you really only use 10–20 of those. Remember, Nginx is just about getting input in from the interwebs to the places it needs to be. That’s it.
Sorry to leave on a cliff-hanger, but at least I know now what the next entry will be on. Thankfully with Node being straightforward as it is, I feel like this next part will be one of my easier encounters with Nginx.
Social Medias!:
Twitter, it’s been like 5 articles. Find your Javascript! (unless they did, then this joke will make no sense)
