Posts made by LibraryMark

I have gotten in the habit of downloading the binaries before the install. It’s just too long to wait for them without knowing what’s going on if you let the install script do it.

I have rolled back to Ubuntu 14.04 and FOG 1.3.5. It works with no issues whatsoever for me.

Sorry I can’t help troubleshoot but I have very little time to work with to get this running.

@george1421
I am curious what php-fpm gains us. I have never had performance issues before.

@george1421
How many versions back do we need to go to bypass this? I think I want to step back in time until the bugs are worked out. Or - what older version of Ubuntu would work better?

@george1421
My multicast sessions usually take about 5-7 minutes to complete. Is that what you mean?

@george1421

Where do I find the “push time”?

I edited the file is /etc/apache2/sites-enabled/001-fog.conf, and it now looks like this:

<VirtualHost *:80>
  <Proxy "fcgi://127.0.0.1:9000">
        ProxySet timeout=300
   </Proxy>

    <FilesMatch "\.php$">
        SetHandler "proxy:fcgi://127.0.0.1:9000/"
    </FilesMatch>
    KeepAlive Off
    ServerName 10.5.0.61
    DocumentRoot /var/www/html/
    <Directory /var/www/html/fog/>
        DirectoryIndex index.php index.html index.htm
    </Directory>
    RewriteEngine On
    RewriteCond %{REQUEST_METHOD} ^(TRACE|TRACK)
    RewriteRule .* - [F]
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
    RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-d
    RewriteRule ^/fog/(.*)$ /fog/api/index.php [QSA,L]
</VirtualHost>

Is that correct? In any case I will not be able to test now because we just opened (public library). It might be a few days.

@george1421
I just upped the memory in/etc/php/7.1/fpm/pool.d/www.conf:

php_admin_value[memory_limit] = 256M 

@librarymark
And after I reboot the server and the multicast actually runs, the PC’s are stuck at this:

and FOG’s webpage says this:

@librarymark
And while trying to multicast 8 pcs, now I get this again:

I am running Ubuntu 16.04 server in vmware. I was never able to make 1.5.4 multicast until I made the changes outlined here to the www.conf file. I was suffering the same things that fry_p had probloms with. Downloading boot.php would just be “…” for days. Now it works (like it used to).

Thank you, george1421!

Edit: Well, I take that back (a little bit). After a 20-pc multicast session, none of the PC’s were able to ‘update the database’. I had to cancel the session, reboot the fog server, and reboot the PC’s . At least the image was successfully blasted out otherwise I would be having a bad day right about now.

@quazz
Oh, so the feature already exists! Wonderful! Thanks!

How do I mark this as solved?

I am using FOG 1.5.4 and have been having various issues, some I’ve created, some that FOG created. I do not trust the database in my current production VM so I have felt the need to start from scratch.

In order to save time, is there a way to “bulk” add hosts? It’s getting pretty tiresome to add them at each seat. IMHO, that would be a great feature to add to FOG, the ability to, say, upload a CVS and having the hosts automatically populated.

Anyway, near as I can tell from the database, all I would have to do is populate the hosts table with hostName, hostImage, and then put the correct host id in the hmID field and MAC address in the hmMAC field and set to ‘1’ the hmPrimary field in the hostMAC table.

Would that do it?

@jj-fullmer Oooh - I found a bug? Cool!

I wonder if the group you created would multicast.

@jj-fullmer

So do most people create the group first, then populate it later?

And -

NOTE: 4.16.6 kernel takes a long time to erase mbr/gpt tables. Downgrading the kernel will make this go faster, but it should be noted that 4.16.6 WILL erase these things, it just takes longer than most are used to.

Well, duh - - I guess I need to start paying more attention!

I updated to 1.5.4.

Can I suggest a progress bar at the downloading binaries step? Or putting them in fog’s download? My ISP is so buggy that It’s hard to tell what’s going on. I have gotten in the habit of pre wget-ing the binaries before the install so I can make sure they download.

But I digress…

I usually create a group at the all hosts screen - I check the hosts I want to add to a group then at the bottom I fill in the create new group field and hit update. When I do that, not only are the hosts I selected in the group, there are many others that I did not select. I remove them, but that’s why makes me think it’s waiting for these “phantom” hosts to come on line before the multicast session starts.

But -

When I go to the groups screen and create a new group, I can click on the new (empty) group, click on membership, then “check here to see what hosts can be added”. I select the hosts, click “add” and then in that group are only the ones I selected. I just now created a test group of 3 PC’s (from the group menu) and was able to multicast to them, however it took a really long time at the “erase the GPT/MBR…” step, long enough that I was looking for this as a possible problem. Then when I got back to the PC’s to take a screen shot the session was running. Is there something in the latest kernel that would cause that?

Anyway, I am wondering - is there a bug in creating a group from the hosts menu, or am I doing something wrong?

Folks - when I try to create a new group, I wind up with several hosts (and the same ones) that show up even if I don’t pick them. Am I doing something wrong?

And a side note, my multicasting is busted now after updating to 1.5.2. Is there anything in the database that would prevent the session from starting? Like it’s waiting for a host in a group that added itself?

Seems to me that in the past when this would happen, I would have to start over as far as entering the hosts.

Here is the tail end of the fog_error file:

● mysql.service - MySQL Community Server
   Loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled)
   Active: active (running) since Mon 2018-04-23 08:07:40 EDT; 2s ago
  Process: 31338 ExecStartPost=/usr/share/mysql/mysql-systemd-start post (code=exited, status=0/SUCCESS)
  Process: 31328 ExecStartPre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/SUCCESS)
 Main PID: 31337 (mysqld)
    Tasks: 29
   Memory: 139.2M
      CPU: 274ms
   CGroup: /system.slice/mysql.service
           └─31337 /usr/sbin/mysqld

Apr 23 08:07:39 fog-server systemd[1]: Starting MySQL Community Server...
Apr 23 08:07:40 fog-server systemd[1]: Started MySQL Community Server.
ERROR 1396 (HY000) at line 1: Operation ALTER USER failed for 'fog'@'127.0.0.1'
Archive:  binaries1.5.2.zip
  End-of-central-directory signature not found.  Either this file is not
  a zipfile, or it constitutes one disk of a multi-part archive.  In the
  latter case the central directory and zipfile comment will be found on
  the last disk(s) of this archive.
unzip:  cannot find zipfile directory in one of binaries1.5.2.zip or
        binaries1.5.2.zip.zip, and cannot find binaries1.5.2.zip.ZIP, period.```

When I try to upgrade to 1.5.2 it always fails with:

 * Copying binaries where needed...............................Failed!

Where do I need to look to figure out this problem?

@Tom-Elliott
That link you posted looks exactly like my problem. When I get a chance, I will re-install the location plugin and see what happens. Is there a db table that is deleted when the plugin is disabled? I looked for a location association table and could not find it.

@Tom-Elliott
Thanks, Tom - I don’t really think it’s anything to do with FOG, as the servers I am using have been thrashed pretty good. I was on trunk for a long time and decided that I needed to get off the daily snapshot roller coaster. I then installed 1.3 over what was there so who knows what state the DB is in. At some point I should probably just start everything over.