@fractal13 said:
Capturing all data up to the first partition was intentional. For GRUB2 bootloaders, the space between the MBR and the first partition is used to store extra data.
I suppose we could put an upper limit on the size though…
I just added an upper limit of 2MiB. @Tom-Elliott will get back to you on what SVN that fix will be introduced by. If you’re impatient, try out the dev-branch of the git repo.
@g.chanaud said:
Can you just guide me to where the partitions creation take place in the case of a resizable image download task ?
https://github.com/FOGProject/fogproject/tree/dev-branch/src/buildroot/package/fog/scripts
The bin directory contains the scripts that fire off the jobs (you’ll want upload and download). The usr directory has the script functions that do all the magic.
@Junkhacker said:
is there a reason you chose to use a mysql query instead of using the built in mechanism of an http request to
<fog-ip>/fog/service/hostname.php?mac=f8:bc:12:6e:67:78&newService=0using the http request, you wouldn’t need to utilize database credentials
Maybe he likes to live dangerously. 
Unfortunately, at this time, 1.2.0 uses a specific kernel. I talked to @Tom-Elliot about it and he said that 1.2.0 probably won’t work properly with a newer init.
Your option at this point is to try out the bleeding edge and see if the latest SVN version serves your needs for now.
I think if you update the kernel inits, it should be supported. My guess is you’re running kernel inits from when you installed 1.2.0. @Tom-Elliott and I have updated the drive detection code to accept more interesting interfaces like mmc cards.
@ch3i said:
@the_duke Hi, I’ve made a script to do that : https://forums.fogproject.org/topic/4510/scripts-customization-of-ubuntu-fog-service-for-ubuntu
You would. 
Thanks for sharing!
3554 appears to have this fixed thanks to Tom.
The change that fixed the excessive DHCP timeouts was 3541. This may not be the most stable commit, but anything after that point will have it fixed.
@Wayne-Workman said:
@cspence Very nice work. Have you seen any performance hits during your testing?
At this point, it’s all about building a working prototype with VMs. But my other testing didn’t show any slow down using samba. Then again, I’m just using plain SATA drives.
Just in case you’re interested: https://github.com/cspenceiv/fog-imager
I have been building a simplified set of imaging scripts. They’ll be fairly similar to what is in use now, but hopefully much easier to read and understand. I’m attempting to get away from a lot of things we currently do.
As of right now, I only have the upload script functional (on an experimental basis). That upload script does not support xfs and jfs (and others that aren’t supported officially by FOG yet). Additionally, it only does multi-disk, multi-partition creates for everything on a system.
Resizability is something I’ll look at later once the basics are taken care of here.
Right now, my test platform is a Arch live disk I built specifically for this testing (that way I’m not testing the buildroot image at the same time). Of course, this is also why I don’t have xfs and jfs support right now (big whoop for this testing).
…and of course, I’m just using samba shares.
@Wayne-Workman said:
@cspence said:
Basically, you don’t have credentials flying around in the clear. You use tickets.
That sounds good.
I was just outlining how some use FOG… didn’t mean to ruffle feathers at all.
Some people do upload images with sensitive stuff on them…
and some people do automated uploads and downloads…
Those are the two main points I wanted to convey.
Don’t sweat it. Tom and I were talking these points over just a moment ago. 
Basically, you don’t have credentials flying around in the clear. You use tickets.
@Wayne-Workman said:
@cspence said:
Kerberizing samba will not get in the way of this. If a job needs to be automated, a read-only account can be used.
Kerberizing? Can that be done on a Linux machine? Say for instance the FOG admin has no windows servers? This is the case for many, many small businesses in U.S. and in countries in South America that can’t afford Windows Server.
Kerberos is an MIT thing, not a Microsoft thing. Also, if you want to emulate active directory, there’s always LDAP/kerberos.
Exactly.
This setup only allows us to improve the integrity of the /images directory over the current setup while confidentiality is still an issue. Then again, if you’re worried about confidentiality, you shouldn’t be doing deployments using FOG or any unencrypted imaging system.
Kerberizing samba will not get in the way of this. If a job needs to be automated, a read-only account can be used.
@eiger3970 said:
Oh, sorry.
I’m so used to Forums shooting down people trying to learn, that I thought it was my fault again and I missed the compatibility checks.Well, that’s good to hear.
Hmm, I guess I’ll have to wait then for some development?
Maybe I’ll try FOG on my Mac then, until the Ubuntu bug is fixed.
Would love to help, but I’m not sure if I could?
Don’t worry, we’re a nice bunch here. In fact, we like getting bug reports. It would be horrible if you guys didn’t give us quick feedback.
@Matt-Rozema said:
It just sits there.
wget http://127.0.0.1/fog/service/getclient.php --2015-06-12 15:12:13-- http://127.0.0.1/fog/service/getclient.php Connecting to 127.0.0.1:80... connected. HTTP request sent, awaiting response...
Can you do the same thing but with the IP swapped out for the one you said FOG would use?
Found the issue. Just forgot a number in the code. It shouldn’t cause any major problems.
Now keep in mind, for some reason, your machine is unable to query the web server during the install. I still need to figure out what’s going on with that…
@Matt-Rozema said:
Yeah, I’m glad it didn’t hang too.
I’m at revision 3543.
Sorry, I meant Linux Distribution/Version (like Debian 7 for example).