Martytoof posted:

I should put the time in to learn Python properly

But in this case it was five lines in Python so that was probably the right tool

xzzy posted:

Well that's programming in general. As business requirements change that nice simple script turns into a bowl of spaghetti.

Methanar posted:

code:

#numbers prefaced with a 0 are interpretted as being an octal number. 
#8 and 9 are not valid numbers within an octal system and will throw an error. 
#Strips off the 0.

lolbash=$(echo $line | awk '{print $3}')
lolbash=${lolbash#0}
echo $lolbash
...
if ! grep -q t$(printf '%02d' $lolbash) < <(awk '{print $4}' $dir/${a}.tmp); then

It's me. I'm the bad person who wrote 2000 lines of bash.

Furism posted:

I'm looking for a simple-ish, fast monitoring solution that Just Works ; to run from a Raspberry. Basically I'd like to be able to monitor my CentOS-running NAS, a MySQL server, maybe health check some website to check WAN connectivity, that sort of things. I don't mind installing agents if I have to (if the said agents are not too troublesome to setup on major distros like CentOS or Raspbian), but SNMP OIDs would be fine too I guess. This is just for some home monitoring so nothing critical. I'd like a clean, light interface with graphs. Does this exist?

xzzy posted:

Shot in the dark: anyone heard of or encountered a issue with OSX 10.12 ssh'ing into a RHEL7 based system?

Got a user who randomly "can't type" on a RHEL7 server. Like, they press spacebar once, get nothing. Press it again and they get a space. Or they're typing a string and input simply stops working for a few seconds. Or they paste a block of text and only part of it makes it across. It's pretty sporadic, it happens "for a while" then goes away "for a while." But it's fine if they do work on a RHEL6 based system. Description makes it sound like network problems but I've eliminated that as a possibility as much as possible. I was about to go down the "well we don't officially support workstations so you're SOL" but then another user piped in that this happens to them "rarely" on their macbook too.

Some kind of weird input bug on a mac maybe? Incompatibility between the ssh client and sshd that decides to throw away characters sometimes?


I spent some time in the google machine and couldn't come up with something but it seems like such a subtle issue, maybe it just hasn't got anyone's attention yet.

Furism posted:

I'm looking for a simple-ish, fast monitoring solution that Just Works ; to run from a Raspberry. Basically I'd like to be able to monitor my CentOS-running NAS, a MySQL server, maybe health check some website to check WAN connectivity, that sort of things. I don't mind installing agents if I have to (if the said agents are not too troublesome to setup on major distros like CentOS or Raspbian), but SNMP OIDs would be fine too I guess. This is just for some home monitoring so nothing critical. I'd like a clean, light interface with graphs. Does this exist?

Volguus posted:

This is a shot in the dark since the solution is available since before the dinosaurs walked the earth (so you probably tried it already), but what is wrong with MRTG for your needs? Worst case scenario ... nagios? It has a bazillion agents, but i personally never tried it. At home I just MRTG and is .... fine. Old,. but fine. And adding scripts (that do whatever that spits out 2 numbers) for it is quite easy.

Furism posted:

I'm looking for a simple-ish, fast monitoring solution that Just Works ; to run from a Raspberry. Basically I'd like to be able to monitor my CentOS-running NAS, a MySQL server, maybe health check some website to check WAN connectivity, that sort of things. I don't mind installing agents if I have to (if the said agents are not too troublesome to setup on major distros like CentOS or Raspbian), but SNMP OIDs would be fine too I guess. This is just for some home monitoring so nothing critical. I'd like a clean, light interface with graphs. Does this exist?

Roargasm posted:

prometheus, prometheus-node-exporter, and grafana all work really good together for this. kind of overkill but a fun project. Prometheus node exporter by itself will expose all your system metrics on a webpage

Furism posted:

Grafana looks sweet as hell, I'm going to try that! Thanks mate.

Thermopyle posted:

You fucker, i already told you to use grafana!

Roargasm posted:

prometheus, prometheus-node-exporter, and grafana all work really good together for this. kind of overkill but a fun project. Prometheus node exporter by itself will expose all your system metrics on a webpage

Furism posted:

Grafana looks sweet as hell, I'm going to try that! Thanks mate.

Docjowles posted:

You still need something to actually poll and store the metrics. But yeah for visualizing things and making sweet dashboards, Grafana owns. And it can do alerting too as of a few versions ago.

Furism posted:

Yes and apparently that'd be Prometheus? For now I'm still setting up the Raspberry. Compiling Go on a Raspberry is not quick. Apparently now InfluxDb offers ARM binaries so I might not even have to compile it myself, but I have to figure out the right way to manually extract the files where they must go because there's no ARM .deb package (just the binaries and files you have to extract).

I might just go "gently caress this" and simply install it on my CentOS NAS though.

Thermopyle posted:

I found telegraf easier to understand and set up.

Furism posted:

Yes I'll use that, mostly I'm struggling a little bit with the InfluxDB setup.

Docjowles posted:

I've always used collectd for the stats-gathering part. Though apparently the "TICK Stack" has been gathering steam. Telegraf is the T in TICK. I wouldn't really describe collectd as easy to understand or setup myself, so I'm interested to hear more about telegraf.

Paul MaudDib posted:

As sort of a holistic exercise in homelab management, I was thinking of setting up a SLURM cluster. To simplify (lol) hardware needs I'd like to PXE boot the nodes from an iSCSI served by my ZFS NAS.

Ideally I'd like to have a base system image with each node getting its own "instance" with copy-on-write type behavior. My "story" for this behavior is something like:

• I make a change to the base image
  
• Backend nodes reboot and PXE boot the new image
  
• As they boot, each node uses some kind of persistent system serial (MAC address? CPUID serial?) to reacquire its old node number
  
• Cluster comes back up with the new version and tasks resume processing
  

My specific questions here are how to do that "re-acquire the node number" part and what is the most effective way to implement the versioning for the filesystem.

If the PXE image is truly immutable then I could just serve a block image, the other way I could go would be to declare a ZFS dataset and have each node clone a snapshot. The advantage of the dataset path seems like a more "natural" filesystem (writeable), and in theory deduplication should be able to keep usage down to the actual shared fileset. I may also have problems with CoW on a block image.

As for the node number... is there something I should be looking towards as a model, like how Docker swarms set themselves up or something? Usually there is not a "persistent" ID, but I'm not sure that having nodes come and go from underneath SLURM's workload scheduler is the best idea.

Methanar posted:

What exactly are you PXE booting to? A RO NFS root? A "live" installation held entirely in ram?

Paul MaudDib posted:

I've never done PXE booting before so I'm fully open to suggestions as to the least painful way to implement this. NFS seems like it might be a decent idea, if all the backend nodes were pulling from a single RO filesystem then all I would have to do is update it and the changes would effectively propagate to the nodes. If the nodes could also get their node ID from a lookup based on the MAC address then the PXE image could be basically immutable.

Paul MaudDib posted:

evol262 posted:

I'd use the motherboard UUID if available. If not, generate one with the MAC as a salt.

Note that RO root support is pretty poo poo in 2017 unless you layer COW or a ramdisk on top of it, and you should expect a million little things to fail (because they're trying to write crap somewhere in /usr/share or whatever)

Vulture Culture posted:

InfluxDB itself isn't terribly complicated, but there are a lot of really weird things the documentation sort of assumes you know about how it works. Where are you getting stuck?

Furism posted:

I'm not sure what the proper way to install it from the tar is. When I untar it I get /var, /usr, /etc directories created, each with subdirectories of its own and files in them. My assumption was that if I sudo untar into / then it should be fine? But I'm not sure because I don't know enough about Linux and the differences between distros (would Debian put/look for the files in the same directory as RHEL? If not, how do I know which distro this tar was made for?).