minor quality of life suggestions for data server installs / builds

[sflanagan]

Affiliation DIII-D

Platform Linux

Description

A few quality of life suggestions regarding installing/building a mdsplus data server.

Suggestion 1

1. The stock /etc/xinetd.d/mdsip file references a logfile directory /var/log/mdsplus/mdsipd, but it doesn't create it and I end up doing a mkdir and chmod -R 775 every server build (after the yum/rpm kit install). I might have asked in ages past, but... was there a specific reason why mdsplus doesn't create it's own log sub-dirs?

Suggestion 2

2. The stock /usr/local/mdsplus/bin/mdsipd files uses $2/access 2>> $2/errors to direct output to logfiles, and I end up changing that to $2/$1.access 2>> $2/$1.errors for (most of) my servers builds so that there's one logfile per service/port. Makes it easier associating traffic/output with the relevant service/port it came through. Thoughts on making that official?

[ModestMC]

@mwinkel-dev am I correct in thinking that these are relatively straightforward modifications?

[WhoBrokeTheBuild]

1. My best guess would be because the xinetd packages come disabled by default, so the thought might've been "you make the directory when you enable them". Regardless, that's a pretty easy change to make. Note: We recommend replacing the xinetd scripts with the new systemd scripts that are packaged, if you can

2. Hmm, I'm worried about changing a standard path, but I do agree that it's better with the $1 in there. One reason we haven't run into this is because we use systemd to manage all our mdsip services. For purpose-built mdsip services, you get their logs with journalctl, and then for the general xinetd/systemd socket mdsip service running on port 8000, you check the single access/errors files. I'm going to hold off on this change for right now, but I'll bring it up at the next mdsplus developer meeting.