Posts made by moses

@Tom-Elliott When I do that and save the changes, the checkbox disappears. Probably should have mentioned that, but since it was listed on the side (in the screenshot), I thought the UI had changed slightly.

Server

• FOG Version: 1.3.0-RC-19
• OS: Centos 7

Description

After updating all my nodes and database server to RC 19, a newly created image (created after the update), doesn’t replicate. Replication is turned on for the image, and I have another node listed where it should be copying to. The replicator log only lists this:

[11-04-16 4:01:37 pm]  | Not syncing Image: W7P-Universal-x64-STANDARD
[11-04-16 4:01:37 pm]  | This is not the primary group.

But it is the primary group!

It should be replicated from the database server on the “HQ” group to another master storage group node in another group.

Any ideas?

@Sebastian-Roth Yeah, I’ve tried all of that. I’m just going to reinstall the OS. Something wonky happened.

@Wayne-Workman It looks like my problem is with SSL. Here’s the output of curl https://google.com:

[root@localhost ~]# curl -I -v https://google.com
* About to connect() to google.com port 443 (#0)
*   Trying 74.125.138.100...
* Connected to google.com (74.125.138.100) port 443 (#0)
* Initializing NSS with certpath: sql:/etc/pki/nssdb
*   CAfile: /etc/pki/tls/certs/ca-bundle.crt
  CApath: none
* Server certificate:
*       subject: CN=*.google.com,O=Google Inc,L=Mountain View,ST=California,C=US
*       start date: Jun 16 08:37:32 2016 GMT
*       expire date: Sep 08 08:29:00 2016 GMT
*       common name: *.google.com
*       issuer: CN=192.168.2.44,C=US
* NSS error -8172 (SEC_ERROR_UNTRUSTED_ISSUER)
* Peer's certificate issuer has been marked as not trusted by the user.
* Closing connection 0
curl: (60) Peer's certificate issuer has been marked as not trusted by the user.
More details here: http://curl.haxx.se/docs/sslcerts.html

Never dealt with this in Linux, any experts out there? This happens with any SSL URL.

@Wayne-Workman Failed again, unfortunately.

@Wayne-Workman I’m on round three, I’ll see if it works this time.

* Downloading inits, kernels, and the fog client..............Failed!

I get the above when trying to update one of my storage nodes. That node is located in a plant that has very slow internet access (~100 KBps). Is it timing out? Any work around?

It’s not behind a proxy if that’s relevant.

It would be great to have an option to disable replication during certain times. Where I work we replicate over an MPLS link that doesn’t have a lot of bandwidth, and all of it needs to be reserved during the day for production stuff.

However, at night or on the weekends is fair game for doing our backups, network discovery tasks, etc. It would be nice to be able to go into FOG and schedule times at which the FOG replication becomes enabled.

Note: Right now I’m doing this using cron (simply disabling replication service at a certain time), so I know that’s an option here, but it would be nice to have it built in. I’m sure I’m not the only person who might use it.

@Tom-Elliott Okay, thanks. I did set it there so I should be good. I’ll mark this as solved for now and if it reoccurs after update I’ll post here again.

Modified /tftpboot/default.ipxe to the correct IP, and that fixed the problem for now, but not sure if it will become a problem again after updating (ie. a database value somewhere that will overwrite it).

I followed the instructions from here: https://wiki.fogproject.org/wiki/index.php/Change_FOG_Server_IP_Address

But when I attempt a network boot, I get the following:

I successfully connect over TFTP, but it’s still trying to get the boot.php script from the old IP. Obviously I missed something somewhere. I’m sure there’s a line somewhere that didn’t get changed.

New IP is 192.168.1.241 and the old IP is 192.168.1.66

Found the problem. Motherboard battery was dead and the power went out yesterday. Date was reset to 2005.

Corrected the date and HTTPS works again, and installed NTP to cover my ass.

I’m not familiar with this error:

[administrator@svr-msn-imaging fogproject]$ sudo git clone --depth 1 https://github.com/FOGProject/fogproject.git .
Cloning into '.'...
fatal: unable to access 'https://github.com/FOGProject/fogproject.git/': Peer's Certificate has expired.

Any idea what I can do to fix that?

@Tom-Elliott Replication now working beautifully. Thanks again Tom!

@Tom-Elliott No, we replaced everything with CentOS (essentially just started fresh today).

One thing I just noticed: when I ran git pull to update, it only pulled down something like 10 MB. When I just tried to update again using sudo git pull, there’s a ton more that needed to be synced…

Going to let that do it’s thing and try again.

Replication is not working between my master server and a freshly installed storage node. There are no files in /opt/fog/log or /var/fog/log on the storage node, but the services start okay as far as I can tell.

Another weird issue is the storage node is returning the string #!db when I go to http://storagenodeip/fog/service/getversion.php

Both servers on newest git version 8038

@george1421 It’s a hypothetical, don’t have any hardware in front of me. I’m using latest trunk though and plan to stay on it, and we are Windows 7 across the board.

Not sure if this has been addressed but I couldn’t find in the forums or Wiki…

If I happen across a computer that doesn’t have any form of network boot option, how can I image it?

@Tom-Elliott No, I found it. Discovered underlying issues with Centos, not FOG, so I’m taking backups of config and images, and reinstalling.

Long story short, systemd got corrupted due to me being an idiot.

@Quazz Centos 7