@AUTH-IT-Center - Thanks for pointing me in the right direction! I knew it was something simple. I had been looking at some of the wiki stuff and forum posts, but they both were a few years out of date, so I wanted to double check before I broke something else! Thanks again for your help!
Posts made by jaoyer
-
RE: Migrating to new Fog Server - Issue
-
Migrating to new Fog Server - Issue
Hi Everyone,
I am having an issue with migrating to a new Fog Server. We had a really old Fog Server that I am trying to replace and to be quite honest, I set up the new fog server months ago and did not document everything that I had done (I know). The web interface is up and working and it looks like I had imported all of our hosts and imported our Fog settings from the old server. I updated the new server’s Fog settings to point to the new Fog Server’s IP address, and I was able to register a new machine. I then tried to upload an image to the new server and it finished the imaging process showing the task was completed on the machine, but then it got to the updating the database and then gave me this error: “Error Returned: Type: 2, File: /var/www/fog/lib/fog/fog.tftp.class.php, Line 470, Message: ftp_login(): Login incorrect., Host: 10.40.22.69 Username: fogproject”
I would assume that it has something to do with importing the old settings and it not matching what I set for the password setting the new server up, but am not sure. If I go to the TFTP section in the web interface, there is a password set there, but it is a long string of random characters. Is there a way to change the TFTP FTP password on the server and the web interface to fix this issue?
Any help would be appreciated!
-
RE: Image Capture FTP Failure - Could Not Create File
Yes. Taking the “/” out of the name fixed my issue.
Thank you guys for all the hard work in developing and maintaining this awesome project.
-
RE: Image Capture FTP Failure - Could Not Create File
HAHA… Ok so this is twice now that I have asked for help on the forums and it has been a stupid simple fix. I am going home.
I changed the name, and it pushed up successfully.
Thanks for your help!
-
RE: Image Capture FTP Failure - Could Not Create File
When I first got this error message, I was trying to update an existing image. I thought maybe it was having trouble overwriting the current image, so I created a new image in the fog web interface, and told it to capture, but still received the error message.
Here is the output of ls -al /images /images/dev
-
RE: Image Capture FTP Failure - Could Not Create File
I connected to it using filezilla and the fog credentials listed in the storage management page. I can upload files into /images. I created just a test text file and it created fine. I edited it and saved it. I then deleted it.
I can see the image that I tried to push up in /images/dev, so I think the image process worked ok, but am not sure about why it failed to update the database at the end.
Thanks!
-
RE: Image Capture FTP Failure - Could Not Create File
I have a little over 162 gb free. I pulled down an image yesterday, and it imaged fine and updated the database fine at the end of imaging. It seems that this issue is only when I try to push and image up to the server.
Thanks!
-
Image Capture FTP Failure - Could Not Create File
Server
- FOG Version: 1.4.2
- OS: Ubuntu 14.04
Client
- Service Version: 0.11.12
- OS: Windows 7
I just updated from 1.40 to 1.42 and tried to capture an image after updating. The image capture completes successfully, but when it tries to update the database, it fails with the following screens.
I saw the troubleshooting FTP wiki article and verified that I can connect to /images with the fog account and password that is listed in storage management. I can create a test file to this directory, edit it, and delete it. This username and password match in all of the areas listed in the wiki
I enabled all permissions on the /images directory using the following
sudo chmod -R 777 /images
I also set the ownership of /images using this:
sudo chown -R fog:root /imagesAny help would be appreciated.
Thanks!
-
RE: IPXE Issues
I think that fixed it. I do have split scope dhcp setup on two servers, and only changed the options on one of them. I changed them in both and it seems to be working fine now.
Feel free to call me an idiot
As far as the updating issue going from 1.30RC10 to 1.40 (detailed in my 2nd response), should I create new thread?
-
RE: IPXE Issues
Option 66 is set to the new server
Option 67 I have set to either undionly.kpxe or undionly.kpxe.INTEL (I’ve tested both).
Cat returns:#!ipxe
cpuid --ext 29 && set arch x86_64 || set arch i386
params
param mac0 ${net0/mac}
param arch ${arch}
param platform ${platform}
param product ${product}
param manufacturer ${product}
param ipxever ${version}
param filename ${filename}
isset ${net1/mac} && param mac1 ${net1/mac} || goto bootme
isset ${net2/mac} && param mac2 ${net2/mac} || goto bootme
:bootme
chain http://10.40.22.67/fog/service/ipxe/boot.php##params -
RE: IPXE Issues
Copying the file over has worked consistently the last 5 times I booted a test machine, so I am fairly certain that that works. However, I am still concerned why it is pointing at the old server. It is my intention to decommission our old server at some point, and am afraid that it will still look to the old server for the default.ipxe file. To test this, I took our old fog server down so that it was completely shut off and booted my test machine . It was still looking for the the default.ipxe file on our old server even though it was down and it eventually timed out.
https://drive.google.com/open?id=0B6yrqHh_joc2bWdYWkZobTlHSmV3TXQyNk9IcklnRG5YLTZv
Is there any cache or anything that I have to clear out on our switches?
How does the “next-server” part of the script work? Is it something as simple as giving the new server an address that comes before the old server?
-
RE: IPXE Issues
3rd time’s the charm…try these:
Picture 1: Failing using the old server address
https://drive.google.com/open?id=0B6yrqHh_joc2d20tWEZzdWcwMVBhckk4V1dZb0Z4MlVvMkprPicture 2: Failing with undionly.kpxe.INTEL with 5 “dots”
https://drive.google.com/file/d/0B6yrqHh_joc2aENyMnJtRE16aFE/view?usp=sharingPicture 3: Working undionly.kpxe.INTEL
https://drive.google.com/open?id=0B6yrqHh_joc2WnBhWUdEemFIQVNqZ1dybzk4RTlOeFFmSENn -
RE: IPXE Issues
Sorry, should have included that. One of our Windows servers handle dhcp.
I tried to update to 1.40 and it went through most of the installation ok, but it failed at the very end connecting to the database and then the webui wouldn’t load (The page isn’t working. Currently unable to handle this request. HTTP ERROR 500). I was reading about php5 vs php7 and assumed there was something in the upgrade from 5 to 7 that caused the webui not to work. I took a snapshot of our server before upgrading so was able to rollback to 1.30RC 10.
That was going to be my next issue that I was going to post. Just for kicks and grins I created a brand new Fog Server and installed 1.40. The install went fine, the webpage loaded , but I still had the same issue booting to default.ipxe with the undionly.kpxe boot file.
I have not migrated all of our images and database yet. That is on my list of things to do this summer. I wanted to get the new server working first. Once I get this working, I do not believe we would need the old server.
Sorry about the images. I can see them in my post, but I am not sure how to make them show up for everyone else. Here are links to them. Can you see these?
Picture 1: Failing using the old server address
https://lh4.googleusercontent.com/v8XwHa7EvGmlAc-9NqToHtVtsfdfcbDoKR-Q-y0feAsv0D-ahsZHipQqqP77P5y2BJ1WeycTgJyMFs4SpaqKDG64f-YfxHhxPAY6=w1920-h941-rwPicture 2: Failing with undionly.kpxe.INTEL with 5 “dots”
https://lh5.googleusercontent.com/iJWYg7W-TOIvJDVcCRDWuGBFcQRXxDrxpyFf3WfgxGJxiZl8cVd-PVGSSLde3PSz15sHYOZeq9DhzT4z6YIFs-n0YsobzVgoISkH=w1920-h941-rwPicture 3: Working undionly.kpxe.INTEL
https://lh5.googleusercontent.com/TepDSUE2fgfP3X-73oCdM3RhF9frvxi32xkRI1vTmAzG7ocUjHEeuBxYnjeEEp0PiJ3vTeoVdWs9wEHFSDy4OQRZOoG2fFnMnNba=w1920-h941-rwI will try copying the default.ipxe file to the old server this afternoon and report back.
Thanks!
-
IPXE Issues
This is going to be kind of long and I apologize in advance for the lengthy post, but I have been tearing my hair out the last week trying to get this to work.
Background: We have been running a FOG server (.32) for the last 6 years and it has been rock solid for us. A few months ago we got some newer computers in that I tried to image using our .32 server. It did not work (tried multiple kernels to get them to boot into the imaging process), so I thought that I would give the newest version a shot. At the time the newest version was 1.30. I installed 1.3.0-RC-10 on Ubuntu 14.04 after trying to get the stable version to image correctly (another long story). When trying to boot using the default undionly.kpxe bootfile, everything would boot fine until it would try to load default.ipxe. The problem it seems is that it is looking on our old FOG Server (10.40.22.66) for default.ipxe and failing, as shown below.
I ended up using undionly.kpxe.INTEL boot file in order to image. When I use undionly.kpxe.INTEL it will not boot load default.ipxe on a consistent basis (maybe every third or fourth time). I have noticed the number of “dots” on the Configuring line will be longer when it works. The first picture is of it failing and has 5 “dots”, the second is of it working with 13 “dots”
I assume that when the it fails with 5 dots that it is looking at our old server and not finding default.ipxe, and when it works it is looking at our new server (10.40.22.67) and loading default.ipxe.
My question is this:
Is there a way to keep our existing .32 server going until I update the Fog Client on the the rest of our computers to point to our new server? Is there anyway I can hardcode our new server’s ip address in the ipxescript and create a custom kpxe file and just bounce back and forth between our old and new server using dhcp options until I migrate everything over?I took a look at the ipxescript located here: https://sourceforge.net/p/freeghost/code/HEAD/tree/trunk/src/ipxe/src/ipxescript
I copied that script into rom-o-matic.eu’s ipxe image page and changed the “chain” line to reflect our new server (chain tftp://10.40.22.67/default.ipxe), but it failed with a params error: command not found; Could not boot: Exec format error.
Looking at the ipxescript, I assume that the undionly.kpxe is finding my old server as “next-server”, and would like to change this to hardcode my new server. We got some new computers in last week that I would like to image with the new server and want to get it so it consistently boots to our new server.
My knowledge of this stuff is pretty limited, so I could use any help that I can get. Thanks in advance.
-
Uploading Other Tag Number #1 through CSV file
I apologize if this has been covered elsewhere, but I was wondering if there was a way to upload data into the Other Tag #1 field through a csv? I have about 200 netbooks that I am migrating from our Clonezilla server to our Fog server. I have successfully uploaded my hosts through a csv file (including the mac, hostname, os id, and image id) , but we include our internal asset tag # and keep it in the other tag #1 field for our other machines. I have sent an inventory task from our fog server to these netbooks, so that page is populated in the web ui. I didn’t know if there was a way to edit [B][COLOR=#0000ff][FONT=Consolas]hosts.upload.include.php[/FONT][/COLOR][/B] file to include this, or create a script to do this. Thanks.