• Recent
    • Unsolved
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Register
    • Login
    1. Home
    2. Nicolas Bricet
    3. Topics
    N
    • Profile
    • Following 0
    • Followers 1
    • Topics 11
    • Posts 39
    • Best 1
    • Controversial 0
    • Groups 0

    Topics created by Nicolas Bricet

    • N

      Unsolved PXE : switches to DOT1X and/or MAB

      FOG Problems
      • • • Nicolas Bricet
      2
      0
      Votes
      2
      Posts
      277
      Views

      george1421G

      @Nicolas-Bricet This really sounds like a spanning tree issue vs dot1x authentication (unless your authentication process is taking a really long time to authenticate the port). Make sure the port is configured for port-fast, fast-stp, rstp or whatever your switch manufacturer calls it.

      Secondly if TIME is the resolution then this can probably be addressed too.

      First of all we have the ability to update the iPXE boot loader from a fog install. This tutorial is intended to solve a different problem but you will need this in your solution: https://forums.fogproject.org/topic/15826/updating-compiling-the-latest-version-of-ipxe

      So at this point you know that you can rebuild iPXE right from your fog server. Now we need to adjust iPXE to wait 30 seconds before requesting an IP address (FWIW, by default spanning tree it take 27 seconds to start forwarding data, so the timing is suspiciously similar).
      When iPXE boots up it runs a FOG custom script file that tells iPXE how to configure itself. If you can remember back to the DOS days, this was the autoexec.bat files function. iPXE has a similar script. Within the iPXE source directory the file is call ipxescript (a look on github) https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src-efi/ipxescript#L1 This is the script that runs inside iPXE to configure the network.

      To take this concept one step more, the FOG developers have already created a version of the iPXE that has a 10 second boot delay (remember you need a 30 second delay). An example of this 10 second delay startup is here: https://github.com/FOGProject/fogproject/blob/a4bb1bf39ac53c3cbe623576915fbc3b5c80a00f/src/ipxe/src-efi/ipxescript10sec#L3 All you need to do is either update that 10 to a 30 or copy that line over to the ipxescript main script and change it to 30. Once that is done recompile ipxe using the instructions above.

      The FOG delivered 10second delay versions of iPXE are located in the /tftpboot/10seconds directory. So you have two paths to get this done, but I would surely look into spanning tree first to make sure port fast is enabled and make the above second way unnecessary.

    • N

      Unsolved Problem Import Host

      FOG Problems
      • • • Nicolas Bricet
      12
      1
      Votes
      12
      Posts
      626
      Views

      jeje3346J

      @NoIPName

      Hey !

      like @Tom-Elliott says , 1.5.10-x is the good way but if your problem is still present so i would ask you this :

      from Fog GUI could you export in CSV your actual hosts list ? could you add in this CSV a new line changing the hostname and mac values could you clean all your hosts from Fog GUI could you import the CSV that you exported

      is it working ?

    • N

      The list all hosts tab takes a long time

      FOG Problems
      • • • Nicolas Bricet
      14
      0
      Votes
      14
      Posts
      980
      Views

      george1421G

      @nicolas-bricet said in The list all hosts tab takes a long time:

      OK what we are going to do is two step process. The first step is to change (remote) some default startup values that will cause a conflict between mariadb, innodb, and a legacy date format that FOG uses.

      The query you ran SELECT @@GLOBAL.sql_mode global, @@SESSION.sql_mode session; shows us the current global settings of

      +-----------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------- ---+ | global | session | +-----------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------- ---+ | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION | ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTI ON | +-----------------------------------------------------------------------------------------------------------------------+-------------------------------------------------------------------------------------------------------------------- ---+

      What we are going to do is remove these startup values

      ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,>> NO_ZERO_IN_DATE,NO_ZERO_DATE,<< ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION

      That will allow the smooth transition between the ISAM data engine and the much faster innodb data engine. Understand this transition may not have a real impact on query times, but we need to rule out some of the deficiencies in the ISAM data engine. Future FOG databases will come native with the innodb format.

      OK back on track.
      We need to find the configuration file for the mariadb (or mysql) server. There is a configuration file in th e/etc directory. The location varies between distributions. I don’t have a current ubuntu server available to give you the exact location so we will need to search for it.

      Run this command as root or sudo grep -R -e 'sql-mode' /etc/* We will look for a file that has an existing sql-mode key. Normally this query should return no files with this in it, but we check just to make sure. If it finds one then skip over the next paragraph.

      We need to find the config file that contans the [mysqld stanza. So as root or an elevated sudo grep -R -e '\[mysqld\]' /etc/* We are looking for a file that has [mysqld] section. Your search might find two files the default is /etc/my.cnf there may be a file in /etc/my.cnf.d directory. If there is one on /etc/my.cnf.d directory edit that one. If none are found we will stop here because we will need to create a config file. Let me know if you hit this roadblock.

      Now that you have found the right config file lets edit it. Under the [mysqld] section insert or edit the line to look like this.

      [mysqld] sql-mode="ONLY_FULL_GROUP_BY,STRICT_TRANS_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ENGINE_SUBSTITUTION"

      Save and exit the editor.

      Now you need to stop and restart mysql

      Once that is done log back into the mysql client program as root and rerun that query to ensure NO_ZERO_IN_DATE,NO_ZERO_DATE have been removed from the startup settings.

      The final command will convert the hosts table from ISAM format to innodb format

      Key this into the mysql client

      use fog; ALTER TABLE hosts ENGINE=InnoDB;

      It should take a few seconds to run.

      Now run the query

      SELECT TABLE_NAME,ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'fog' and ENGINE = 'MyISAM';

      You should see the hosts table in innodb format.

      Now run your hosts management query in the web ui. What are the results.

      While we are at it (after you do the above test) we probably should convert the rest of the tables in case there are any joins going on in the queries and also to have a consistent db format.

      Run this query (copy and paste will be your friend here. You can paste the query in all in one go.

      ALTER TABLE LDAPServers ENGINE=InnoDB; ALTER TABLE clientUpdates ENGINE=InnoDB; ALTER TABLE dirCleaner ENGINE=InnoDB; ALTER TABLE globalSettings ENGINE=InnoDB; ALTER TABLE greenFog ENGINE=InnoDB; ALTER TABLE groupMembers ENGINE=InnoDB; ALTER TABLE groups ENGINE=InnoDB; ALTER TABLE history ENGINE=InnoDB; ALTER TABLE hookEvents ENGINE=InnoDB; ALTER TABLE hostAutoLogOut ENGINE=InnoDB; ALTER TABLE hostMAC ENGINE=InnoDB; ALTER TABLE hostScreenSettings ENGINE=InnoDB; ALTER TABLE hosts ENGINE=InnoDB; ALTER TABLE imageGroupAssoc ENGINE=InnoDB; ALTER TABLE imagePartitionTypes ENGINE=InnoDB; ALTER TABLE imageTypes ENGINE=InnoDB; ALTER TABLE images ENGINE=InnoDB; ALTER TABLE imagingLog ENGINE=InnoDB; ALTER TABLE inventory ENGINE=InnoDB; ALTER TABLE ipxeTable ENGINE=InnoDB; ALTER TABLE keySequence ENGINE=InnoDB; ALTER TABLE location ENGINE=InnoDB; ALTER TABLE locationAssoc ENGINE=InnoDB; ALTER TABLE moduleStatusByHost ENGINE=InnoDB; ALTER TABLE modules ENGINE=InnoDB; ALTER TABLE multicastSessions ENGINE=InnoDB; ALTER TABLE multicastSessionsAssoc ENGINE=InnoDB; ALTER TABLE nfsFailures ENGINE=InnoDB; ALTER TABLE nfsGroupMembers ENGINE=InnoDB; ALTER TABLE nfsGroups ENGINE=InnoDB; ALTER TABLE notifyEvents ENGINE=InnoDB; ALTER TABLE os ENGINE=InnoDB; ALTER TABLE oui ENGINE=InnoDB; ALTER TABLE plugins ENGINE=InnoDB; ALTER TABLE powerManagement ENGINE=InnoDB; ALTER TABLE printerAssoc ENGINE=InnoDB; ALTER TABLE printers ENGINE=InnoDB; ALTER TABLE pxeMenu ENGINE=InnoDB; ALTER TABLE scheduledTasks ENGINE=InnoDB; ALTER TABLE schemaVersion ENGINE=InnoDB; ALTER TABLE snapinAssoc ENGINE=InnoDB; ALTER TABLE snapinGroupAssoc ENGINE=InnoDB; ALTER TABLE snapinJobs ENGINE=InnoDB; ALTER TABLE snapinTasks ENGINE=InnoDB; ALTER TABLE snapins ENGINE=InnoDB; ALTER TABLE supportedOS ENGINE=InnoDB; ALTER TABLE taskLog ENGINE=InnoDB; ALTER TABLE taskStates ENGINE=InnoDB; ALTER TABLE taskTypes ENGINE=InnoDB; ALTER TABLE tasks ENGINE=InnoDB; ALTER TABLE userCleanup ENGINE=InnoDB; ALTER TABLE userTracking ENGINE=InnoDB; ALTER TABLE users ENGINE=InnoDB; ALTER TABLE virus ENGINE=InnoDB; ALTER TABLE wolbroadcast ENGINE=InnoDB;

      Now run the query again to see if I missed any tables.

      SELECT TABLE_NAME,ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'fog' and ENGINE = 'MyISAM';

      If I missed any tables just create your own ALTER TABLE commands

      OK so why INNODB format over ISAM. There are many reasons but the most impactful is that ISAM has table locking on an update where INNODB only locks the row on an update. So when there is an update query for ISAM only one writer is allowed at a time for the entire table even if the second writer and the first writer are updating different rows in the table. INNODB only locks the row that is going to be changed leaving other processes to be able to write to other rows and move on. This change is most impactful when you have many FOG Client computers hitting the server every 5 minutes. SO since you are doing a read query when access the hosts via the web ui, this change may not have an impact at all. BUT we need to rule out ISAM as the performance drag on your system.

    • N

      Associate an image with a site

      General Problems
      • • • Nicolas Bricet
      3
      0
      Votes
      3
      Posts
      389
      Views

      Wayne WorkmanW

      This is interesting, I can see how it could be useful, though understand it would take valuable developer cycles for a thing that perhaps could be achieved in another way using existing features, without development efforts. @Nicolas-Bricet have you considered the following? setting an image for hosts in a particular site via groups, such that when imaging happens, the host’s image which is already set is used.

    • N

      Default profile - LDAP connection

      General Problems
      • • • Nicolas Bricet
      4
      0
      Votes
      4
      Posts
      484
      Views

      Wayne WorkmanW

      I think he’s asking for a default role via the access control plugin. @Fernando-Gietz any thoughts on that?

    • N

      One FOG server for multiple teams

      General
      • • • Nicolas Bricet
      3
      0
      Votes
      3
      Posts
      1.4k
      Views

      Wayne WorkmanW

      @Nicolas-Bricet said in One FOG server for multiple teams:

      To avoid, for example, accidental deletions of images.

      The latest version of Fog records who deletes what images in the history table, in the DB. I had this come up once and asked the senior devs to record who, and they implemented it.

      Also in the latest version, there is a checkbox called “Protected” for each image - when this is enabled, fog won’t let the image be overwritten or deleted via the GUI.

      Both of those functionalities are only available in 1.3+

      You could provide an account to people for the duration of imaging only, then delete their account. You could provide accounts only to your top tier folks, and give everyone else mobile access - so they have to be at the physical boxes in order to image them. Or you could just trust folks, they can do it - you just have to teach them how to do things safely, how stuff works. Let the knowledge flow instead of having a monopoly on it.

      I would not recommend a multi-master setup.

      I come from a school district at my last job, from a department of about 30 people with the same title, “equals” on paper. We had a 14ish server FOG setup - one master and the rest all storage nodes at all the various schools in the district. Everyone had a fog account. In all training I gave about FOG, I always stressed the responsibility that everyone had to have to use fog - and to be extra careful. Out of 2 years usage and that many people in one big system, there were no significant issues. Just pound it into their heads that they must be responsible - and to ask if they don’t know. Extend an olive branch and show them how things work.

    • N

      Release of the final version 1.3.0

      General
      • • • Nicolas Bricet
      2
      0
      Votes
      2
      Posts
      1.0k
      Views

      Q

      There are no scheduled release dates. FOG is entirely worked in free time of the developers, so it would be impossible to schedule any target dates, realistically.

      That being said 1.3 is on RC11 right now, so you can perhaps draw some conclusions from that.

      Soon TM

    • N

      Solved Active Directory Mac OS X

      Mac Problems
      • • • Nicolas Bricet
      26
      0
      Votes
      26
      Posts
      12.9k
      Views

      J

      @Nicolas-Bricet I’m not sure if you are still following this thread but all known os x binding issues have been resolved and tested as of v0.11.4. (We finally got testing environment in place for us to test this).

      I will be marking this thread as solved, if you still have issues let me know and I’ll re-open it.

    • N

      Solved Boot PXE - UEFI

      FOG Problems
      • • • Nicolas Bricet
      9
      0
      Votes
      9
      Posts
      5.4k
      Views

      S

      Trying to find out what exactly goes on there in the ipxe code as well as asking google. But this UEFI iPXE stuff is such a vast and complicated world. From the errors I see (“cannot read PCI configuration: No such device” and “is not supported by driver ‘PCI’”) it sounds like the NIC is not designed according to the standard UEFI implementation. Maybe it’s just a UEFI GUID not matching or what. I don’t know for sure.

      By the way, which NIC was this? Can you please let us know which NIC exactly you are trying to boot from?

      The iPXE dev team is great and might be able to help you with this. Try getting in contact with them on their forum or via IRC.

    • N

      Solved PXE Surface PRO 3

      Hardware Compatibility
      • • • Nicolas Bricet
      11
      0
      Votes
      11
      Posts
      6.2k
      Views

      Wayne WorkmanW

      @Nicolas-Bricet

      We are requesting that all community members who have Surface Pros to please do a packet capture, to capture the DHCP conversation the client sends out at boot time via the ethernet dock, and upload the capture here. The intent is to gather more information about the Surface Pro, so fog can better support network booting it.

      Thanks,
      Wayne

    • N

      Solved Boot PXE Macbook - Imac

      Linux Problems
      • • • Nicolas Bricet
      17
      0
      Votes
      17
      Posts
      23.7k
      Views

      S

      @Nicolas-Bricet Thanks for reporting back on this! I am still working on improving this article. Knowing what works and what not for different machines is very helpful. I am marking this thread as solved. If you see new issues with Mac OS you might want to open up a new post.

    • 1 / 1