Best posts made by Wayne Workman

I’d personally want to see this wait until fog-too.

@jloke said:

Looks like we’ll use the realtek file to take care of this laptop, then change back to undionly for our general use.

@george1421 said:

But the idea is that you will use the system’s guid to dictate what kpxe file the dhcp server will reply to the client.

If the Vendor Class identifier is unique from other models, it’d be easier to use a vendor class identifier in ISC-DHCP. We already have an extensive article detailing how to do this:
https://wiki.fogproject.org/wiki/index.php?title=BIOS_and_UEFI_Co-Existence#Building_custom_DHCP_Classes_for_co-existence_with_FOG

@Jordonlovik said:

At this point I am strongly considering a full reinstall of the server. Although it was labor intensive. I was just starting to experience the wonder of FOG imaging too. and I love it.

I’d recommend CentOS or Fedora. These instructions basically work for both: https://wiki.fogproject.org/wiki/index.php/Fedora_21_Server

Sounds like you now need to troubleshoot FTP.

Take a look at this: https://wiki.fogproject.org/wiki/index.php/Troubleshoot_FTP

Let us know if you figure it out, or if you need more help.

Here’s a hint… Credentials

I disagree. I like it exactly how it is.

If I set a setting on my “ALL BUILDING COMPUTERS” group for joining to AD, That’s cool, because at that moment, I want to make sure all building computers are set to join to AD using whatever credentials I put in.

However, later on, when I’m updating an image and I disable domain joining for a particular computer - so that it does not join the domain when I deploy an image to it, and so I can update and re-upload without mucking up my image, I definitely do not want groups to just automatically re-tick the join domain checkbox.

There are other examples, too. I don’t want any changes made to the group functionality.

@Matthieu-Jacquart Don’t give up. Guys like you are exactly what FOG needs to move forward. Your work with Sebastian is VERY appreciated by the whole fog community!

@Jordonlovik I don’t prefer things that aren’t Red Hat based. I’m studying for my RHCSA and RHCE, and if an employer wanted to use Linux, they generally choose RHEL for the support that Red Hat offers.

If you’d like to create a tutorial for Kubuntu, please go ahead and post it in the tutorials area for everyone. And obviously we try our best to help people use whatever distro of Linux they want. @Tom-Elliott is really the guy who makes it work on just about everything.

@afmrick

That’s very interesting. Another guy is having the exact same issue (I think), but he’s found another work around (equally unacceptable in nature though).

Try making a simbolic link to /images/780/d1p2.img.001, pointing at the actual files… I bet it’d work.

[CODE]ln -s /images/780/d1p2.img /images/780/d1p2.img.001[/CODE]

Then ensure the sym-link has the right permissions:
[CODE]chmod 777 /images/780/d1p2.img.001[/CODE]

If that works for you, we can build a script that can do this for all of your images in mere seconds.

Let us know, I’m very interested.

@Arrowhead-IT said:

What if you forget the automation part of my feature request and focus on the persistent part. As I’m utilizing groups more and more I would really like it if I didn’t have to manually select snapins and printers everytime. It is convenient to be able to add the same things but I’d like to have a static template type of thing. Every host in this group needs these snapins type of thing. Maybe I’ll just make it a plugin at some point if I ever get any extra time

That’s a much better approach.

But I’d say that “templates” should be a special kind of group - it’s just a group that you can actually save settings to. Then - when you want those applied you’d just go to that group and click an “Apply” button with the settings you previously put in already there for each of the settings areas.

I suppose we could create a fake host for each template - and have the template groups auto-load settings from the fake hosts - just as the regular hosts auto-load their own settings from the DB.

Still a far cry from being done though.

@Sebastian-Roth Doing my best.

./installfog.sh -y

For more options, look at ./installfog.sh --help

Those arguments for the installer are currently only available in Trunk, which is FOG 1.3.0 beta.

Oh and 1.2.0 might be the “stable” release, but it’s probably got more bugs than the Trunk version at this point.

1.2.0 is quite aged when you compare it to the Trunk version. You’ll also find increased performance in Trunk, and a wider range of supported hardware.

And, everyone that hangs here has seen time and time again how fast Tom (the senior developer) can squash a bug. Most of the time though, it’s user error and not bugs.

And if you want to do any Win8 imaging, you’ll need the Trunk version.

@Sebastian-Roth I’ve not heard a thing from that building’s techs about this issue. If they try to get this model working with FOG in the future, I’m sure they will Google search it and find this thread, wouldn’t that be humorous?

I’m working with one of them tomorrow, I’ll ask about it.

@pugnacious a local path that is already remote cannot be re-exported in Linux.

You’d be better off just setting up a Read/Write NFS Share on your Windows Storage server, and setting up an account for FTP Access to that share for FOG. Then you’d just add that as a storage node in FOG.

@ITBOYS said:

Just looking back and the image size on the server still displays zero.

The server size would display zero if the images are stuck in /images/dev

Did you look at the credentials section of that article?

@george1421 said:

We can script it - I’m confident we can.

@george1421 fixparts /dev/sda

However, this only affects uploads.

I think something else is going on.

@pugnacious

This looks pretty good - it’s mostly got the right ideas. https://wiki.fogproject.org/wiki/index.php?title=Windows_Storage_Node

Mainly, the NFS functionality needs READ access for /images and READ/WRITE for /images/dev

You need two files, called .mntcheck one is located /images/.mntcheck and the other is /images/dev/.mntcheck These are just empty files. The upload/download scripts that fog uses will look to see if these files exist. If they can see them, it means that the NFS share mounted properly, see?

The NFS functionality can be tested with steps found here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_NFS

The FTP functionality needs Read/Write on everything in the /images directory, recursively (or inherited in windows). Then that username and password need used to create a new Master storage node inside it’s very own storage group on the fog server.

The user account for FTP can be tested with steps found here: https://wiki.fogproject.org/wiki/index.php?title=Troubleshoot_FTP

The FTP Path inside of the storage node settings in the FOG web interface can be tricky - the only way to verify that is by testing FTP manually using the steps above.

is it an SSD?

Try single disk - resizeable. and under “partitions”, choose “everything”.

Also - a photo of the error you’re seeing would help greatly.