• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. jms
    3. Posts
    J
    • Profile
    • Following 0
    • Followers 0
    • Topics 4
    • Posts 14
    • Best 4
    • Controversial 0
    • Groups 0

    Posts made by jms

    • RE: Install to / boot from SAN support (FC, not FCoE)

      Thanks – I will add the Emulex drivers and rebuild the kernel for FOS - I believe that will get me 90% of the way there and I will at least be able to capture/deploy images etc., although I may need to add some user space tools as well (for multipath etc). Can you tell me which Linux distro FOS is based upon - or if it is a completely custom Linux OS in case I need additional user space packages to install or compile?

      I will also post to the iPXE message boards about native FC HBA support or also utilizing the EFI FC HBA driver (already loaded during POST) when wanting to boot directly to the FC LUN from iPXE menu.

      posted in Hardware Compatibility
      J
      jms
    • Install to / boot from SAN support (FC, not FCoE)

      It appears that while iPXE supports FCoE via sanboot, there is no support for traditional FC HBA booting. In my physical server environment, all systems are boot-from-FC-SAN and have no local drives whatsoever.

      Without FC HBA support (Emulex in my case), I don’t believe there is a way for iPXE to boot from the local hard drive from the menu system, as FC HBA drivers simply are not present. FCoE works because it’s over the ethernet adapters which are supported and do have drivers in iPXE.

      rEFInd should be able to go back to UEFI and from there boot from the FC LUN that was attached during EFI POST when the Emulex EFI ROM was loaded – however this is also not working for me. I have not performed any significant troubleshooting steps on this, so it may be possible.

      I am loading iPXE via the server BMC via iPXE ISO, so my workaround there is to simply reboot to the FC LUN after imaging is finished - and this is satisfactory.

      However, my biggest issue is that I cannot create/deploy images using FOG against my FC LUNs, I assume because the FOG OS does not contain Emulex FC drivers and hence the same issue occurs. I’m wondering if anyone here has successfully solved this problem, or if you could point me to the right resource on compiling drivers and creating new kernel/ramdisk for FOG OS that would include the Emulex drivers so that I can at least create/deploy images using FOG? As mentioned, I’m less worried about booting from the FC LUN from the iPXE menu as I am about having an imaging solution in general.

      Thanks !!

      posted in Hardware Compatibility
      J
      jms
    • RE: working-1.6 "Deploy Image" from iPXE menu fails with HTTP Error 5xx

      @Sebastian-Roth Yes it is working now - thank you !!

      posted in Bug Reports
      J
      jms
    • working-1.6 "Deploy Image" from iPXE menu fails with HTTP Error 5xx

      In working-1.6 when I choose “Deploy Image” from the iPXE menu, on a host that is registered, and choose to deploy any image the operation fails immediately with the following:

      http://192.168.X.X/fog/service/ipxe/boot.php... HTTP 5xx Server Error (http://ipxe.org/1d0c6639)
      Cloud not boot: HTTP 5xx Server Error (http://ipxe.org/1d0c6639)
      Could not boot image: HTTP 5xx Server Error (http://ipxe.org/1d0c6639)
      

      The iPXE error URL redirects to a more generic error (1d0c66) that is deprecated and no longer used.

      I did find the following in www-error.log:

      12-Nov-2018 15:02:29 UTC] PHP Fatal error: Undefined class constant 'DEPLOY' in /var/www/html/fog/lib/fog/bootmenu.class.php on line 1271
      

      In an identically configured “working” branch (working-1.5) system, this issue is not present. Additionally in the working-1.6 system, I can successfully schedule a test for an image to be deployed to said host and that tasks executes and completes successfully.

      (By the way - please let me know if there is a better way to submit bugs or if the forum is the right place!!)

      posted in Bug Reports
      J
      jms
    • RE: Detect if PXE client is already iPXE

      @Sebastian-Roth Thanks that all makes sense.

      Thanks Sebastian — from my point of view I could still get rid of TFTP by recognizing either UEFI HTTP Boot (physical hardware) or existing iPXE ROM (in my Nutanix VM) vi DHCP headers (vendor class / user class) and in either case chainload the FOG iPXE binary (with “params” enabled) via HTTP and eventually perhaps HTTPS.

      This should be pretty straightforward, I’ll see if I can work it out and I’ll post back - may be worth a wiki article.

      Now … the next item to tackle would be replacing FTP (vsftpd) with SFTP 🙂

      Feel free to close this thread if it’s no longer appropriate as a “feature request”.

      posted in Feature Request
      J
      jms
    • Detect if PXE client is already iPXE

      This would have the impact of potentially removing the need for TFTP for those PXE clients and using only HTTP or perhaps even HTTPS at some point.

      For example, lets say I have a VM running on Nutanix, which by default uses SeaBIOS and iPXE as the boot ROM. It’s a bit redundant to load undionly.0 and then ipxe.0 and then proceed down the path of booting into the FOG menus.

      It’s fairly straightforward to get an existing iPXE ROM to load a script or menu via HTTP using DHCP …

      ISC DHCP

      if exists user-class and option user-class = "iPXE" {
          filename "http://${next-server}/fog/service/ipxe/boot.ipxe";
      } else {
          filename "undionly.kpxe";
      }
      

      DNSMASQ

      # The dhcp-match sets the ipxe tag for requests from iPXE.
      # iPXE sends a 175 option
      dhcp-match=set:ipxe,175
      
      # The boot filename, Server name, Server Ip Address
      dhcp-boot=tag:!ipxe,undionly.kpxe,,192.168.X.X
      dhcp-boot=http://${next-server}/fog/service/ipxe/boot.ipxe,,192.168.X.X
      

      May also be able to use the DHCP option “user class” in dnsmasq.conf, but the above works just fine. I have only tested in proxy mode but it does work just fine … my DHCP server will be off-limits in production.

      So, trying this I copied over /tftpboot/default.ipxe into /var/www/fog/services/ipxe/boot.ipxe.

      The first thing that happened when dnsmasq sent over boot.ipxe as the file to load, exception thrown because all of the “params” and “param” statements in that file were of course not recognized by my iPXE boot ROM causing an exception and halting any progress. Based on a quick look through boot.php in the ipxe directory and then other php code further up the chain (bootmenu.class.php etc), I assume these are PHP arrays and variables. Of course, the FOG-provided chain loaded iPXE ROM seems to load just fine - so perhaps “default.ipxe” is the wrong place for me to start … I’m still digging around 🙂

      Now, if I trim back boot.ipxe (default.ipxe) to instead contain only the following, I successfully boot to the FOG menu … however it has no styling or background PNG, only plain ncurses type PXE menu but all of the standard FOG options are there.

      #!ipxe
      cpuid --ext 29 && set arch x86_64 || set arch ${buildarch}
      chain http://${next-server}/fog/service/ipxe/boot.php?mac=${net0/mac}
      

      Now from here all I tried to do was click on the deploy image option and again I was given an exception stating that “params” was an unknown.

      I’m going to continue to poke around, because obviously FOG is already working properly via iPXE once it’s chain loaded from undionly. So, I believe this may not require much in the way of codebase change, but perhaps configuration change.

      As a side note, for physical hosts my plan would be to utilize UEFI HTTP Boot to load the iPXE ROM (vs using the Intel hardware PXE ROM) and then loading up the same boot.ipxe script via HTTP as shown above. Goal would be to eventually move all of this to HTTPS, but … baby steps!!

      If you have any quick tips about where to look next that would be appreciated. I think as you look to the future and using UEFI HTTP(S) Boot and removing the hard requirement for TFTP for that initial undionly.0 for folks that may not want TFTP installed, this could be a good feature request.

      posted in Feature Request
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      @Sebastian-Roth Yes your fix does indeed resolve the issue for me – thank you sir !!!

      posted in FOG Problems
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      @Sebastian-Roth I tried against “working” branch (1.5.x working), setup identically to the other 2 VMs and fog installations, and it works flawlessly, same as stable (head? – sorry I’m not that up to speed on git terminology!) … so, seems the issue lies squarely in working-1.6

      Happy to continue to test and debug - just let me know how I can help.

      posted in FOG Problems
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      Update. I created 2 identical CentOS 7.5 vm’s, configured them 100% identical.

      On on I installed fog from the git clone and on the other I used git to checkout working-1.6 and install. All fog installation parameters were exactly the same for both servers.

      On the regular git cloned fog installation, everything works as expected.

      On the working-1.6, I get the same error as before, after image captured, updating database … failed.

      So I agree, something with 1.6

      I’m happy to help troubleshoot further. I’ll poke around on my own but if there are some things you would like for me to try I’d be happy to participate.

      Thanks !!

      posted in FOG Problems
      J
      jms
    • RE: working-1.6 ... During image creation: Updating Database ..... Failed

      Ok, that page has some useful tips, although the mysql portion(s) are a bit circular regarding the number of different mysql users required. Is there a single mysql user/pass for everything in fog, or is the storage node mysql credentials different?

      I did not set a password for mysql during installation.

      .fogsettings shows no user/password/host for snmysql*

      Web UI shows a user of “fogstorage” along with a password for FOG_STORAGENODE_MYSQLUSER/MYSQLPASS

      config.class.php shows a user of “root” and no password under function _dbSettings, and shows user “fog” with the correctly set password for STORAGE_FTP_USERNAME/PASSWORD, as set by passwd for the Linux system user “fog”

      When I run the mysql credentials test with no user/pass against the fog db it works fine, but when I try against the storage user listed in the Web UI I get the following …

      [root@fogsrv ~]# mysql -U fogstorage -pPASSWORDHERE -D fog
      ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
      
      posted in FOG Problems
      J
      jms
    • working-1.6 ... During image creation: Updating Database ..... Failed

      Running image creation task … using working-1.6 (pulled within the past week) … after image creation complete, I get the dreaded “updating database … failed … retry etc etc etc”

      I have followed all instructions regarding permissions of /images (chmod -R 777, chown fog:root), and I have followed all instructions related to passwords.

      I have updated “fog” Linux user password using passwd and have updated the storage node configuration, the fog ad user/pass and the fog tftp user / pass. I have also updated /opt/fog/.fogsettings.

      I get the following error in php-fpm/www-error.log …

      [09-Nov-2018 02:06:30 UTC] PHP Warning: ftp_delete(): Delete operation failed. in /var/www/html/fog/lib/fog/fogftp.class.php on line 106
      [09-Nov-2018 02:06:30 UTC] PHP Fatal error: Call to a member function rename() on boolean in /var/www/html/fog/lib/reg-task/taskqueue.class.php on line 362
      

      And yet, from my Mac desktop I can use Filezilla to successfully ftp to my fog server using the user/pass that I have setup everywhere else and can traverse the entire filesystem remotely via Filezilla and the fog user credentials, so I know that vsftpd is working.

      When I monitor /images/dev during image creation … the image is actually xferred and saved in a directory there.

      What can I try next? No other logs appear to have anything of consequence, but I could be missing it I suppose.

      Of note, my mysql db is running with no user/password as allowed during fog setup - but I can easily access the db using ‘mysql -D fog’.

      I’m running on CentOS 7.5.

      posted in FOG Problems
      J
      jms
    • RE: FOG 1.6 Testing Needed - Help would be greatly appreciated as needed

      @Sebastian-Roth I set SElinux to permissive and rebooted and now have full access to the web application. Are there any tips/tricks to get this to work in a more secure environment? My customer will require it.

      posted in Announcements
      J
      jms
    • RE: FOG 1.6 Testing Needed - Help would be greatly appreciated as needed

      @Sebastian-Roth … SELinux maybe the culprit? This is the entire contents of /var/log/httpd/error_log

      [Tue Oct 30 15:18:54.950152 2018] [core:notice] [pid 18968] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
      [Tue Oct 30 15:18:54.951263 2018] [suexec:notice] [pid 18968] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
      [Tue Oct 30 15:18:55.024509 2018] [auth_digest:notice] [pid 18968] AH01757: generating secret for digest authentication …
      [Tue Oct 30 15:18:55.025440 2018] [lbmethod_heartbeat:notice] [pid 18968] AH02282: No slotmem from mod_heartmonitor
      [Tue Oct 30 15:18:55.045190 2018] [mpm_prefork:notice] [pid 18968] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.6.38 configured – resuming normal operations
      [Tue Oct 30 15:18:55.045219 2018] [core:notice] [pid 18968] AH00094: Command line: ‘/usr/sbin/httpd -D FOREGROUND’
      [Tue Oct 30 16:02:57.220914 2018] [mpm_prefork:notice] [pid 18968] AH00170: caught SIGWINCH, shutting down gracefully
      [Tue Oct 30 16:03:13.796605 2018] [core:notice] [pid 1099] SELinux policy enabled; httpd running as context system_u:system_r:httpd_t:s0
      [Tue Oct 30 16:03:13.799657 2018] [suexec:notice] [pid 1099] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec)
      [Tue Oct 30 16:03:13.873692 2018] [auth_digest:notice] [pid 1099] AH01757: generating secret for digest authentication …
      [Tue Oct 30 16:03:13.874639 2018] [lbmethod_heartbeat:notice] [pid 1099] AH02282: No slotmem from mod_heartmonitor
      [Tue Oct 30 16:03:13.928936 2018] [mpm_prefork:notice] [pid 1099] AH00163: Apache/2.4.6 (CentOS) OpenSSL/1.0.2k-fips PHP/5.6.38 configured – resuming normal operations
      [Tue Oct 30 16:03:13.928975 2018] [core:notice] [pid 1099] AH00094: Command line: ‘/usr/sbin/httpd -D FOREGROUND’

      posted in Announcements
      J
      jms
    • RE: FOG 1.6 Testing Needed - Help would be greatly appreciated as needed

      Having some trouble on CentOS 7.5 (with all updates). Everything seems to go fine and I can log into the web console and then just get to a blank page. Happens on both Safari and Firefox (latest versions).

      Here are my steps … CentOS 7.5 VM – fresh install, freshly updated and rebooted.

      #> cd /opt
      #> git clone https://github.com/FOGProject/fogproject.git
      #> cd fogproject
      
      #> git pull
      #> git fetch --all
      #> git checkout working-1.6
      
      #> cd bin
      #> ./installfog.sh
      

      Set up as Fog server with DHCP and gateway, but not DNS. Then updated firewall …

      #> for service in http https tftp ftp mysql nfs mountd rpc-bind proxy-dhcp; do firewall-cmd --permanent --zone=public --add-service=$service; done
      #> firewall-cmd --permanent --add-port=49152-65532/udp
      #> firewall-cmd --permanent --direct --add-rule ipv4 filter INPUT 0 -p igmp -j ACCEPT
      #> systemctl restart firewalld
      

      Next completed the database install via the GUI and completed the text based installer with no issues. But as I’ve said I get sent to the following URL which is just a blank page in both browsers I tried …

      https://XXX.XXX.XXX.35/fog/management/index.php?node=home

      I have attached the full text output of the installation process.

      Sorry - I’m sure I’ve missed something simple and obvious – but can anyone spare a few minutes to take a look and provide some guidance? Thank you !!
      0_1540930468007_Fog Installation Log.txt

      posted in Announcements
      J
      jms
    • 1 / 1