RC26 - Please physically associate images to a storage group
-
Server
- FOG Version: RC26
- OS: CentOs 7.2.1511
Client
- Service Version: n/a
- OS: n/a
Description
Day 2 with the same brand new build from scratch of OS and FOG and I’m seeing this unusual text appearing on my non-logged in console.
Checking if I am the group manager. I am the group manager Starting Image Replication. We are group ID: 1. We are group name: default We are node ID: 1. We are node name: DefaultMember Attempting to perform Group -> Group image replication. There is nothing to replicate. Please physically associate images to a storage group.This is a standalone server, no storage nodes; as I’ve always created, so the configuration is documented rote.
Storage Node and Storage Group are all FOG default-generated by the installer. Images are associated okay. In fact everything about the FOG server appears to be working as intended, but this text.
Now typically I would work by telnet/SSH, but I happened to have left my console open and noticed this.
-
@sudburr while I’m aware of how this can occur I’ve also fixed it so that shouldn’t happen moving forward
-
In the mean time please edit the snapins and make sure the group has the primary flag set. It will present the right messages if you do this for your snapins. You may also need to do similar for images.
-
… but I have no snapins.
Do you mean that for each image I should:
- Edit image definition
- Select Storage Group
- Select the Primary Group Selector tick box for ‘default’
- Select Update Primary Group
?
-
@sudburr Yes.
-
Clickety-click. Barba-trick. Done, plus a server reboot for good measure and woah! Holy wall o’text Batman.
Not syncing Image between nodes Image Name: <Image #1 name> There are no other members to sync to. Not syncing Image between nodes Image Name: <Image #2 name> There are no other members to sync to.… eventually leading two mismatched rows of
+------ +---Then an <enter> from me brings up the login prompt.
Now is that expected?
-
@sudburr You can change the TTY it’s printing to? BUt yes, somewhat expected. The idea is to tell you the status of each of the images (even if you aren’t doing replication).
-
Hmm, something else that’s interesting happened.
When I first performed steps 1-4 … the page would refresh and look the same as it did when I first went to it, except for three images. These three images came back with the green checkmark in place of the tick box. I happened to have performed steps 1-4 on these three images twice.
Rebooting and checking again, those same three still have the tick but all others didn’t. Performing steps1-4 again on the recalcitrant images and they finally came back with the green check mark and it survived a reboot.
-
Okay, so the wall o’text is more or less expected with this RC and the fixes you had me perform. Now it is the dump that occurs periodically via the console instead of the original text I posted.
… but is that wise? To dump status information like that to an unmanned console interface where any Tom, Dick or Jane walking by can see? Not that any Tom, Dick or Jane will be walking by my servers, but the point is that potentially sensitive information could be displayed without anyone being logged in.
-
@sudburr Of course, but you can change where these are written to (in console).
Each of the services have a default tty (and they should all be different, though it wouldn’t hurt anything to have them on the same).
The idea, I think, is so make users more aware of the services and that they are running and any issues that might be happening. I don’t know how any information printed out by the services would be “sensitive” unless your file names are in such a way it might give out PII or confidential/sensitive information. In that case, though, you can just change the TTY for the services within FOG Configuration -> FOG Settings -> FOG Linux Service TTY Output (I think).
