@varun-r Please provide:
@lebrun78 said in Choising a storage management:
if i rename /images to /imagesold and create a new /images where is mount //fog032/images and then copy the contents of /imagesold to the new /images, it should works, no ?
It will work. I’ve done a lot of stuff like this before. Dedicating an entire physical partition on a physical disk is the simple way to go about it but it’s not exactly flexible by design. LVM solves those problems. If you’re using logical volume groups and logical volumes, you don’t have to do all of that mess you were talking about (transferring, renaming), you just add space to the volume group, then the logical volume.
@Developers @Moderators
I messaged him in chat and ping’d him here in the thread.
I’m thinking that forking threads isn’t good because people may bookmark the original thread they posted in. He might have came back to the original thread via a bookmark and seen that all his new posts were just gone…
I think that locking threads is a better option once the issue is solved, or we have looser customs about people addressing their next issue in their original thread. With the forums searching functionality, it may not be such a bad idea to just let folks keep going in the original thread. Also, another option is after forking, leave a link behind for them to find where the fork went to. Maybe that should be a feature in nodeBB? Auto-link to the fork, and maybe even send an email to the individual who’s posts were forked? Maybe even auto-message them too with the link and a short message of what happened.
@bmick10 Just set dodhcp to N inside of your /opt/fog/.fogsettings file and re-run the installer.
More information: https://wiki.fogproject.org/wiki/index.php?title=.fogsettings#dodhcp
After you re-run the installer, you should try to turn off the DHCP service with systemctl stop dhcpd;systemctl disable dhcpd
Add another nic, configure it for your production network, add a new storage node for the new ip and put it in the same storage group as the other. You can configure dhcp on the fog server to not serve to the prod network by creating a blank subnet definition.
I can help/explain a lot more when I’m home, I’m on lunch right now.
@Tony-Lillie said in Unable to capture win7 image:
What is the FOS client??
@george1421 likes to come up with snazzy-sounding acronyms. “FOS” is “FOG Operating System” (which could be further expanded to… Free Open Ghost Operating System). It’s the environment that the uploads and downloads and other network-boot based tasks happen in. That’s all.
If you would run a debug task as George asked, and follow his instructions and provide the requested outputs, it would help us greatly in our effort to help you.
@fettforce Can you post a scrubbed/sanitized copy of your unattend.xml file? Please use the code-block tool.
@Tony-Ayre said in How big can Snapins be now?:
@Wayne-Workman Why is that? 2+GB files aren’t really that big.
If you’re deploying just 1, then it isn’t big. Deploying snapins to 200 computers, that’s 400GB. Deploy that to 550 computers, that’s over 1TB, I’ve done bigger than this. And the best way to do it is to limit max clients.
@arduinoAndMore I’ve found some information on that error, they all refer to inconsistencies on the drive, unmounting issues, inaccurate detection of how big the drive is, or other issues related to malware/viruses.
https://sourceforge.net/p/clonezilla/discussion/Help/thread/de8ea4fe/
https://sourceforge.net/p/clonezilla/bugs/167/
http://serverfault.com/questions/438243/cloning-bitmap-free-count-err-on-proxmox-drive
http://ubuntuforums.org/showthread.php?t=2082868
http://www.saetechnologies.com/clonezilla-bitmap-error-at-group/
My advise to you is to re-upload the image and try again.
Also, is this a Windows image or an OSX/Linux image? If it’s windows, do a checkdisk. OSX also has some filesystem fixing things too, just can’t remember their names.
Ah, just read this is Lubuntu.
@dureal99d said in How does fog see drives in a system:
Linux sees my drive as /dev/sdc1, however a booting fog sees my same boot drive drive as /dev/sdd1
Make sure you don’t have any SD cards stuck in the system. Also is the hard disk a hybrid drive (flash and mechanical)? Did you install Linux on the system or are you just live booting from a flash drive?
Can we get the output of lsblk please?
@michael_f said in Snapin script interrupted by Hostname Changer before completion (I think):
@ITSolutions I am using network shares too, and agree with you that deleting the connection at the end and using a restricted account is a quite good idea.
But I still can’t see the security risk in putting the credentials in the script:
The script is stored on the fog server, which should be secure.
It is afaik sent to the client encrypted if using the new fog client.
On the client-side the script is executed with system-privileges, so an eventually logged in user can’t access the script? Or is the script saved readable in a temporary file?
If the credentials are sent encrypted to the server by the “net use”-command (which I assume), how can somebody get access to the credentials?Maybe I got something wrong? I would really apreciate, if someone could clarify this.
It wouldn’t be difficult to snatch the script with the clear-text passwords in it from the server. It would be a matter of having a MAC (or list of MACs) from your environment (easy), finding the FOG Server’s IP (easy), and then writing a basic script to guess at the taskid. Then it’s just a matter of iterating through a most-probable range of task IDs and through a single or large list of MACs with GET requests… like this one:
http://10.2.1.11/fog/service/snapins.file.php?mac=90:B1:1C:98:03:8C||00:00:00:00:00:00:00:E0&taskid=3274
The most-probable range of task IDs is easy to determine by looking at any c:\fog.log file. Even if you couldn’t access the log to determine a most-probable range of task IDs, you could just iterate through 5,000 of them and likely hit the valid one. Once a valid one is hit, the snapin download starts. An attacker wouldn’t even need to know the task’s name or any associated files names.
Plain-Text passwords are never secure.
No idea, haven’t used Windows in a year.
The installation files are available in a nice bundled package - but I’d really recommend just using git to manage your installation files. I’d even say it’s simpler.
You’ve already used git I would think because you’re on an RC, but you might have uses svn, I don’t know… If you’ve used git to get the RC you have, all you need to do is navigate to your fogproject directory, wherever you put it.
If you have no idea where that is, you can find it like this:
find / | grep /fogproject/bin/installfog.sh
That command translates to english as:
Find all files, start the search in the base directory - pipe the output to grep, and only display output that has the path /fogproject/bin/instalfog.sh somewhere in it.
That should give you where the fogproject directory is. Just cd to there and run git pull and then when that’s done, run git checkout master and then cd into the bin directory and launch the installer with ./installfog.sh -y
If the find command doesn’t return anything, you’re best just following the wiki article and pull down a fresh copy of the fog repository. More details here:
https://wiki.fogproject.org/wiki/index.php?title=Upgrade_to_trunk
You can also Google search “switching git branches” and “update git repository” to get a wealth of information.
@K.Hays said in UEFI-PXE-Boot (Asus t100 Tablet):
all other computers work just fine to image.
This is what you should be doing: https://wiki.fogproject.org/wiki/index.php?title=Simple_Redirect
@K.Hays He’s talking about your dhcp server’s scope options. Option 066 should already be correct as you said fog works for other computers. Option 067 needs set to ipxe.efi for this device only, or to snponly.efi @Scott-Adams hit on this point earlier.
It might be worthwhile to run wireshark on the DHCP server to see if it’s even getting a request for DHCP from the device. Also, what are you connecting to as far as the network goes? We know you’re using the adapter, but can you put a dumb-switch (aka a mini-switch) between the adapter and the rest of the network and see what that does?
George’s steps will absolutely work - because George is just that kind of guy. His stuff works. I am so sure of this that I didn’t even read what he wrote - I just assume he’s correct.
But I’ve faced this exact problem before and I solved it by adding the storage node as the master to my new server’s default group. This way replication goes from the old storage node -> New server. I let that run and sync - and after it was done I removed master from the old node and applied master to the new one. Of course image definitions must exist on the new server for this to happen - you have to recreate these either way.
Related article: https://wiki.fogproject.org/wiki/index.php?title=Replication
@arnaudrigole said in Image hosting on NFS server, process uncompleted?:
/informatique/Service_info/FOG/images
That’s your FTP path.
FOG Trunk supports independent FTP paths, which you need.
@Junkhacker I suspect the same.
Or, it could possibly be something else. Remember that time I was beating my head against the wall for a week over why the fog server was crippled? Turned out it was a broken fiber cable left laying unfixed for a week by a piece-of-trash contractor that should have been fired.
Not saying it’s a broken fiber cable but… it could be the last thing you would expect, something very wild and off the wall.