@tian said in finally switched from 0.32 to 1.4.4:

when all computers are starting simultaneously there are more deploying at the same time than allowed in the storage node’s “max clients” option: e.g. 13 are allowed and it has been 14 to 16 for the first deploy batch of a room, the later computers normally will start when it is below 13 again but it can happen that 2 will start at the same time again (depending on the moment they try to check in I think) and it might be 12->14 again

That’s a known problem - it’s caused by a race condition. It is a minor problem since everything still works and sort-of stays within the boundaries.

@jackiejack said in Could not complete tasking /bin/fog.upload:

That long string in .configure file is the password?

Yes that is the password and not the hash. The password for the linux user fog should have never been password. That is the default password for the web gui admin called fog yes I know its confusing. I really wish the developers long time ago would have change one of them to something different to avoid the confusion.

@tom-elliott THANKS!

@jackiejack No one will get angry. We all were “new” at one time. You are learning what you can and can’t do. FOG is a really complex system with several other open source systems under the hood. Its not something you can pick up and run with on day one. The developers have done a great job of hiding the complexities inside fog with the nice web ui.

😄
Got it.
Will read up on tutorials more carefully.
Thanks for all your help.
J

@x23piracy Not sure I am understanding the question

@wayne-workman Just tried, it works! 🙂 thanks

Search is still not working for me (tried it 5 seconds ago):

Bild Text

@jveronese the combination of subnet mask and IP address will say they are on the same subnet.

i.e. 192.168.1.0 with a subnet mask of 255.255.255.0 would say they are on the same subnet.

OK if they are on the same subnet, we can use fog to see if we can detect what is going wrong with dhcp.

Follow these instructions and then upload the pcap to a google drive. We’ll take a look at the capture and see what is going on with dhcp
https://forums.fogproject.org/topic/9673/when-dhcp-pxe-booting-process-goes-bad-and-you-have-no-clue

@tom-elliott said in Do you have to image over the network to use fog?:

Technically yes. But fog is not designed for this.

Said the senior developer who knows ‘it’s possible’.

@keith75140 I say don’t even try because that’d be sort of like trying to build a house using an F-16 jet fighter instead of a general contractor…

If you want to image without networking, Clonezilla is the right tool for that.

I’m having a problem where my Ubuntu desktop freezes and I restore it from a back up. When I do that it does not sync with my /images/ folder where all of my images are. I’ve created my own CSV file to upload into fog, however, I’m running into the problem of figuring out the size and server size, so what goes into column G and R. If someone can help me figure out those two pieces of information from the images I already have I would appreciate it. Thank you.

@SlimJim Did you get to test this on a release candidate installation? Should be working there already.

I’d say adjust the /opt/fog/.fogsettings file and let the fog installer handle configuring DHCP (It is solid, I’ve done a lot of work on that part of the installer). You’ll probably need to install dhcp-server before hand though.

@tom-elliott said in FOG, what can and can't it do?:

I feel I must add the primary reason you won’t see a “central repository” for OS images lies down with the very simplistic case of licensing.

If there were a “central” repository, um, can you imagine the legal issues that would no doubt-ably ensue? Managing a repository itself would be extremely difficult, but licensing - especially in commercial OS’s - would be a nightmare.

Ultimately, while it would - from a purely technical standpoint - be possible to create a (very very very) generic set of OS’s that could be used by many, this would not come with your organizations set of software. (Admittedly vague in that you could automate some of the software layout with snapins.) This again is purely technical. Yes, it “could” be done. No, it most likely will not be done.

I could, however, understand central repo for OS’s that don’t require licensing (only one I can think of would be linux though) but even then you’re dealing with one person’s preferences for the layout of the OS vs. what might actually be required and/or more suitable to your environment.

OS-Images - generally available and upgradable with snapins (kinda) is the idea behind docker.com…

@wayne-workman hyphen was needed for legacy client

Ok thanks.

You could do something like a batch file

@echo off reg add xxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Then add that into your snap ins and deploy it!

Thanks.
It is solved.

@jjcjr With your concerns then the remote site will need to have a stand alone storage node, just for the reason you cited. If the master node is unreachable then imaging isn’t possible.

What you are asking for is not currently available in fog (what I’ve been calling a multi master node setup. I’ve personally had a feature request in for this for over 2 years). The developers have just added a restful api interface that was on the roadmap to provide what you are asking. But its not there just yet.

With your current setup, you only need to export from the master node and import into the remote node when you have a new image definition. If you update an existing image definition, the new files will be replicated to the remote fog server and nothing else is needed. This is how I run my multi-master fog setup.

@predator On the web console, what does it say is the assigned image for that host?