Posts made by geardog

geardog

Took me a while to circle back to this, but it’s nice to have it working as expected.

geardog

Thanks for that. I get the same result in my slightly newer version.
I updated the post to show my OS and version.

geardog

This server is a fresh ubu 22.04 with fog 1.5.10.41, but as I’m having trouble getting data into fog and it behaving, I’ve removed fog files, dropped sql dbase, and reinstalled fog numerous times.

On first install/config import the hosts and images appear, but the storage node info disappeared.
I get an unauthorized page when trying to export host and image CSVs.
Dropping failed sql dbase import and reinstalling fog brings back storage node info so I try manually entering the host and image info then exporting them for a “clean install,” but trying to export CSV gets an unauthorized page still.

I’ve tried every un/pw combo I can find
UN: root
PW: xxx

Desc.: local user
UN: local_admin
PW: xxx

Desc.: Fog storage nodes
UN: fogstorage
PW: [as found in config gui]

Desc.: TFTP server
UN: fogproject
PW: [as found in config gui]

Desc.: initialiazation
UN: fog
PW: password

Desc.: wiki tip
UN: localhost
PW: [blank]

Desc.: wiki tip
UN: local loopback
PW: [blank]

Desc.: wiki tip
UN: localhost
PW: [local user pw?]

Desc.: wiki tip
UN: local loopback
PW: [local user pw?]

and while I’ve read this
https://wiki.fogproject.org/wiki/index.php?title=Migrate_FOG
I’m trying to use the gui.

I’d love to be able to export a CVS from my newly installed server, but … what gives?

geardog

Installed ubu 22
fstab mount big drives at /images
installed fog without dhcp
restored a fog config
installed dnsmasq with the suggested config
see my hosts and images in UI dashboard
start client capture task
mounting file system failed
could not mount images folder /bin/fog.upload
args passed reason mount mounting <fog_IP>/images/dev on /images failed permission denied

checked and reset permissions via chown fogproject:root and chmod 777
.mntcheck is there
I reinstalled fog just to overwrite any old restored config settings that might be lingering and I get the
update /opt/fog.fogsettings message
Well it didn’t note that I also needed to update the fogproject pw, but I had different values in the .fogsettings vs the dashboard so made them match …
reinstall fog, and it’s clean, but the snmysqluser=‘fogstorage’ in .fogsettings I was told to use in install messages has reverted to fog master, and now I cant see my node usage? Default member is unauthorized…

still can’t mount the folder …

uhg does any of this make sense to anyone?

::edit:: ehhh just wiped the fog stuff and reinstalled
node is back to showing, but all host and image data is gone
merging two config backups and will restore one with just the good stuff from both

so it’s capturing an image
not sure why I couldn’t sort out credentials after restoring a config

geardog

@sebastian-roth
Wow, so is my only known option for external storage making the NAS behave as a storage node? It has a flaky proprietary OS/GUI that has warning everywhere. “You will brick me if…”

geardog

@sebastian-roth
So I’ve edited fstab to mount the images folder (on the NAS) with NFS, it shows up in dashboard, and I can write to it from fog terminal. I’m still, however, getting the same error upon trying to deploy an image to the box. Thoughts?

netadmin@V-Ubu-Fog:/media/Images$ df -h
Filesystem                          Size  Used Avail Use% Mounted on
udev                                395M     0  395M   0% /dev
tmpfs                                88M  952K   87M   2% /run
/dev/mapper/ubuntu--vg-ubuntu--lv    20G  7.5G   12G  41% /
tmpfs                               439M     0  439M   0% /dev/shm
tmpfs                               5.0M     0  5.0M   0% /run/lock
tmpfs                               439M     0  439M   0% /sys/fs/cgroup
/dev/sda2                           976M  390M  520M  43% /boot
/dev/loop0                           56M   56M     0 100% /snap/core18/1988
/dev/loop1                           56M   56M     0 100% /snap/core18/1997
/dev/loop2                           70M   70M     0 100% /snap/lxd/19188
/dev/loop3                           71M   71M     0 100% /snap/lxd/19647
/dev/loop4                           33M   33M     0 100% /snap/snapd/11402
/dev/loop5                           33M   33M     0 100% /snap/snapd/11588
/dev/sda1                           511M  7.9M  504M   2% /boot/efi
//172.17.17.201/Backup__Desk-1      3.7T  2.9T  844G  78% /media/4TBusb
//172.17.17.201/Data                7.3T  4.4T  3.0T  60% /media/Data
//172.17.17.201/VMs                 7.3T  4.4T  3.0T  60% /media/VMs
tmpfs                                88M     0   88M   0% /run/user/1000
172.17.17.201:/shares/Images        7.3T  4.3T  3.0T  60% /media/Images
netadmin@V-Ubu-Fog:/media/Images$

netadmin@V-Ubu-Fog:/media$ ls -l
total 8
drwxr-xr-x  2 root root    0 Apr 14 17:15 4TBusb
drwxr-xr-x  2 root root    0 Mar 11 01:30 Data
drwxrwxrwx 22 1003 root 4096 Apr 14 19:25 Images
drwxr-xr-x  2 root root    0 Feb  7 05:50 namespace
drwxr-xr-x  4 root root 4096 Apr  9 13:40 test
drwxr-xr-x  2 root root    0 Dec 15 15:43 VMs
netadmin@V-Ubu-Fog:/media$ cd Images
netadmin@V-Ubu-Fog:/media/Images$ ls -l
total 84
drwxrwxrwx 2 501 netadmin 4096 Apr  5 15:28 1old-images1
drwxrwxrwx 2 501 netadmin 4096 Mar 21  2019 aero0-
drwxrwxrwx 2 501 netadmin 4096 Mar 21  2019 Alpha0-
drwxrwxrwx 2 501 netadmin 4096 Mar 21  2019 Alpha1-
drwxrwxrwx 2 501 netadmin 4096 Apr  4  2019 conf-desk---
drwxrwxrwx 4 501 netadmin 4096 Jan 28 18:09 dev
drwxrwxrwx 2 501 netadmin 4096 Mar 21  2019 Engineering1
drwxrwxrwx 2 501 netadmin 4096 Mar 21  2019 Engineering3
drwxrwxrwx 2 501 netadmin 4096 May 23  2019 inspection1---
drwxrwxrwx 2 501 netadmin 4096 Mar 22  2019 inspection2-
drwxrwxrwx 2 501 netadmin 4096 Mar 22  2019 inspection-CMM--
drwxrwxrwx 2 501 netadmin 4096 Mar 22  2019 inspection-OGP-
drwxrwxrwx 2 501 netadmin 4096 Mar 22  2019 postdownloadscripts
drwxrwxrwx 2 501 netadmin 4096 Mar 22  2019 sales-04--
drwxrwxrwx 2 501 netadmin 4096 Jun 25  2019 sales-acc
drwxrwxrwx 2 501 netadmin 4096 Mar 22  2019 scot-pc--
drwxrwxrwx 2 501 netadmin 4096 Apr  4  2019 ship-main-
drwxrwxrwx 2 501 netadmin 4096 Mar 22  2019 shipping-
drwxrwxrwx 2 501 netadmin 4096 Mar 22  2019 tc-
-rw-r--r-- 1 501 netadmin    3 Apr 14 19:25 text
drwxrwxrwx 2 501 netadmin 4096 Mar 22  2019 ubu1
netadmin@V-Ubu-Fog:/media/Images$


root@NAS Images # ls -l
drwxrwxrwx    2 nobody   share         4096 Apr  5 10:28 1old-images1
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 Alpha0-
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 Alpha1-
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 Engineering1
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 Engineering3
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 aero0-
drwxrwxrwx    2 nobody   share         4096 Apr  4  2019 conf-desk---
drwxrwxrwx    4 nobody   share         4096 Jan 28 12:09 dev
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 inspection-CMM--
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 inspection-OGP-
drwxrwxrwx    2 nobody   share         4096 May 23  2019 inspection1---
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 inspection2-
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 postdownloadscripts
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 sales-04--
drwxrwxrwx    2 nobody   share         4096 Jun 25  2019 sales-acc
drwxrwxrwx    2 nobody   share         4096 Mar 21  2019 scot-pc--
drwxrwxrwx    2 nobody   share         4096 Apr  4  2019 ship-main-
drwxrwxrwx    2 nobody   share         4096 Mar 22  2019 shipping-
drwxrwxrwx    2 nobody   share         4096 Mar 22  2019 tc-
-rw-r--r--    1 nobody   share            3 Apr 14 14:25 text
drwxrwxrwx    2 nobody   share         4096 Mar 22  2019 ubu1
root@NAS Images #

I’m stumped again.

geardog

@sebastian-roth
I made the image folder public, and it didn’t change anything.
It’s actually mounted in fstab using cifs utils, and the NAS shows it has NFS support. I’ll look into a different way to mount it.

geardog

Reason: mount: mounting 172.17.17.82:/media/Images/ on /images failed: Permission denied

I have migrated fog from a physical server to a VM and have moved image storage from said physical server to a NAS folder which is mounted at /Images on the fog VM. The storage location is entered in the default storage node attributes. The node comes up as expected in the dashboard, and old captured images are seen in dashboard as well. Based on the message and having read some of the similar error messages, I suspect permission issues, but I’m not sure how to address them.

I’m running fog 1.5.9

netadmin@V-Ubu-Fog:/media/Images$ df -h
Filesystem                          Size  Used Avail Use% Mounted on
udev                                395M     0  395M   0% /dev
tmpfs                                88M  972K   87M   2% /run
/dev/mapper/ubuntu--vg-ubuntu--lv    20G  7.5G   12G  41% /
tmpfs                               439M     0  439M   0% /dev/shm
tmpfs                               5.0M     0  5.0M   0% /run/lock
tmpfs                               439M     0  439M   0% /sys/fs/cgroup
/dev/sda2                           976M  390M  520M  43% /boot
/dev/loop0                           56M   56M     0 100% /snap/core18/1988
/dev/loop1                           56M   56M     0 100% /snap/core18/1997
/dev/loop3                           71M   71M     0 100% /snap/lxd/19647
/dev/loop2                           70M   70M     0 100% /snap/lxd/19188
/dev/loop4                           33M   33M     0 100% /snap/snapd/11402
/dev/loop5                           33M   33M     0 100% /snap/snapd/11588
/dev/sda1                           511M  7.9M  504M   2% /boot/efi
//172.17.17.201/Backup__Desk-1      3.7T  2.9T  844G  78% /media/4TBusb
//172.17.17.201/Images              7.3T  4.4T  3.0T  60% /media/Images
//172.17.17.201/Data                7.3T  4.4T  3.0T  60% /media/Data
//172.17.17.201/VMs                 7.3T  4.4T  3.0T  60% /media/VMs
tmpfs                                88M     0   88M   0% /run/user/1000
netadmin@V-Ubu-Fog:/media/Images$

netadmin@V-Ubu-Fog:/media/Images$ lsblk
NAME                      MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
loop0                       7:0    0 55.5M  1 loop /snap/core18/1988
loop1                       7:1    0 55.5M  1 loop /snap/core18/1997
loop2                       7:2    0 69.9M  1 loop /snap/lxd/19188
loop3                       7:3    0 70.4M  1 loop /snap/lxd/19647
loop4                       7:4    0 32.3M  1 loop /snap/snapd/11402
loop5                       7:5    0 32.3M  1 loop /snap/snapd/11588
sda                         8:0    0   35G  0 disk
├─sda1                      8:1    0  512M  0 part /boot/efi
├─sda2                      8:2    0    1G  0 part /boot
└─sda3                      8:3    0 33.5G  0 part
  └─ubuntu--vg-ubuntu--lv 253:0    0   20G  0 lvm  /
netadmin@V-Ubu-Fog:/media/Images$

netadmin@V-Ubu-Fog:/media/Images$ sudo touch /images/{,dev/}.mntcheck && sudo chmod -R 777 /media/Images
netadmin@V-Ubu-Fog:/media/Images$

image storage from fog

netadmin@V-Ubu-Fog:/media/Images$ ls -l
total 0
drwxr-xr-x   2 root root 0 Apr  5 15:28 1old-images1
drwxr-xr-x   2 root root 0 Mar 21  2019 aero0-
drwxr-xr-x   2 root root 0 Mar 21  2019 Alpha0-
drwxr-xr-x   2 root root 0 Mar 21  2019 Alpha1-
drwxr-xr-x   2 root root 0 Apr  4  2019 conf-desk---
drwxr-xr-x   2 root root 0 Jan 28 18:09 dev
drwxr-xr-x   2 root root 0 Mar 21  2019 Engineering1
drwxr-xr-x   2 root root 0 Mar 21  2019 Engineering3
drwxr-xr-x   2 root root 0 May 23  2019 inspection1---
drwxr-xr-x   2 root root 0 Mar 22  2019 inspection2-
drwxr-xr-x   2 root root 0 Mar 22  2019 inspection-CMM--
drwxr-xr-x   2 root root 0 Mar 22  2019 inspection-OGP-
drwxr-xr-x   2 root root 0 Mar 22  2019 postdownloadscripts
drwxr-xr-x   2 root root 0 Mar 22  2019 sales-04--
drwxr-xr-x   2 root root 0 Jun 25  2019 sales-acc
drwxr-xr-x   2 root root 0 Mar 22  2019 scot-pc--
drwxr-xr-x   2 root root 0 Apr  4  2019 ship-main-
drwxr-xr-x   2 root root 0 Mar 22  2019 shipping-
drwxr-xr-x   2 root root 0 Mar 22  2019 tc-
drwxr-xr-x   2 root root 0 Mar 22  2019 ubu1
netadmin@V-Ubu-Fog:/media/Images$

image storage from NAS

root@NAS Images # ls -l
drwxrwxrwx    2 fog      share         4096 Apr  5 10:28 1old-images1
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 Alpha0-
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 Alpha1-
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 Engineering1
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 Engineering3
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 aero0-
drwxrwxrwx    2 fog      share         4096 Apr  4  2019 conf-desk---
drwxrwxrwx    4 fog      share         4096 Jan 28 12:09 dev
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 inspection-CMM--
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 inspection-OGP-
drwxrwxrwx    2 fog      share         4096 May 23  2019 inspection1---
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 inspection2-
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 postdownloadscripts
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 sales-04--
drwxrwxrwx    2 fog      share         4096 Jun 25  2019 sales-acc
drwxrwxrwx    2 fog      share         4096 Mar 21  2019 scot-pc--
drwxrwxrwx    2 fog      share         4096 Apr  4  2019 ship-main-
drwxrwxrwx    2 fog      share         4096 Mar 22  2019 shipping-
drwxrwxrwx    2 fog      share         4096 Mar 22  2019 tc-
drwxrwxrwx    2 fog      share         4096 Mar 22  2019 ubu1
root@NAS Images #

netadmin@V-Ubu-Fog:/media/Images$ sudo chown fog 1old-images1
[sudo] password for netadmin:
chown: invalid user: ‘fog’

The image folder is mounted using smb credentials of a user “fog” created on the NAS, and I can create files on the mount from fog based on those credentials. I’ll happily change this to clear any ambiguity, but I’m chasing my tail I think.
Where am I?

geardog

@sebastian-roth So I’m not sure what has changed, as I’ve had to focus on other things, but now it works. I didn’t follow the most recent direction, but I’m booting various boxes via pxe successfully. No idea. …

geardog

@sebastian-roth
What does this get me into? Will I have to recreate/replace these when I reinstall fog? I may be ham fisted, as I’ve probably reinstalled fog 15 times during my use of it. I’d like to be aware of complications in SOP, moving forward.

geardog

@sebastian-roth
Well, I made the following edit in ltsp.conf


# Set the root directory for files available via FTP.
tftp-root=/tftpboot/10secdelay

rebooted the fog vm
no apparent change in behavior…
Chainloading still fails, and shell>config output shows no proxydhcp section

geardog

@sebastian-roth

aye, confirmed

sticky slash key

geardog

@sebastian-roth

so a montage of my poking around
In short, after chainloading fails and I run config, there is no proxydhcp listed
when I run dhcp net0 from shell
I then get fog popping up in proxydhcp with the correct ip

What does this mean?

net0

net0

proxydhcp

geardog

@sebastian-roth
No adjustments have been made. I was waiting for this to play out.

geardog

@sebastian-roth said in connection timed out chainloading failed:

tcpdump -i enp5s0 port 67 or port 68 -e -n -vv

No mention of next server.

[root@Clear0 etc]# tcpdump -i enp17s0f0 port 67 or port 68 -e -n -vv
tcpdump: listening on enp17s0f0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:24:14.566873 1c:6f:65:83:a0:95 > Broadcast, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 20, id 1, offset 0, flags [none], proto                                                                                                    UDP (17), length 576)
    0.0.0.0.bootpc > 255.255.255.255.bootps: [udp sum ok] BOOTP/DHCP, Request from 1c:6f:65:83:a0:95, length 548, xid 0x6783a095, secs 8,                                                                                                    Flags [Broadcast] (0x8000)
          Client-Ethernet-Address 1c:6f:65:83:a0:95
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Discover
            Parameter-Request Option 55, length 36:
              Subnet-Mask, Time-Zone, Default-Gateway, Time-Server
              IEN-Name-Server, Domain-Name-Server, RL, Hostname
              BS, Domain-Name, SS, RP
              EP, RSZ, TTL, BR
              YD, YS, NTP, Vendor-Option
              Requested-IP, Lease-Time, Server-ID, RN
              RB, Vendor-Class, TFTP, BF
              Option 128, Option 129, Option 130, Option 131
              Option 132, Option 133, Option 134, Option 135
            MSZ Option 57, length 2: 1260
            GUID Option 97, length 17: 0.49.67.54.70.54.53.56.51.65.48.57.53.255.255.255.255
            ARCH Option 93, length 2: 0
            NDI Option 94, length 3: 1.2.1
            Vendor-Class Option 60, length 32: "PXEClient:Arch:00000:UNDI:002001"
11:24:14.567192 00:15:17:c4:a9:92 > Broadcast, ethertype IPv4 (0x0800), length 366: (tos 0xc0, ttl 64, id 2182, offset 0, flags [none], pr                                                                                                   oto UDP (17), length 352)
    172.17.17.1.bootps > 255.255.255.255.bootpc: [bad udp cksum 0xbe6f -> 0x1006!] BOOTP/DHCP, Reply, length 324, xid 0x6783a095, secs 8,                                                                                                    Flags [Broadcast] (0x8000)
          Your-IP 172.17.17.191
          Server-IP 172.17.17.1
          Client-Ethernet-Address 1c:6f:65:83:a0:95
          Vendor-rfc1048 Extensions
            Magic Cookie 0x63825363
            DHCP-Message Option 53, length 1: Offer
            Server-ID Option 54, length 4: 172.17.17.1
            Lease-Time Option 51, length 4: 43200
            RN Option 58, length 4: 21600
            RB Option 59, length 4: 37800
            Domain-Name Option 15, length 22: "xxx"
            Domain-Name-Server Option 6, length 12: 172.17.17.16,172.17.17.17,172.17.17.1
            Default-Gateway Option 3, length 4: 172.17.17.1
            BR Option 28, length 4: 172.17.17.255
            Subnet-Mask Option 1, length 4: 255.255.255.0
11:24:14.574606 00:15:5d:02:0a:16 > Broadcast, ethertype IPv4 (0x0800), length 374: (tos 0xc0, ttl 64, id 10347, offset 0, flags [none], p                                                                                                   roto UDP (17), length 360)
    172.17.17.82.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 332, xid 0x6783a095, secs 8, Flags [Broadcast] (0                                                                                                   x8000)
          Server-IP 172.17.17.82
          Client-Ethernet-Address 1c:6f:65:83:a0:95
          file "undionly.kpxe"[|bootp]
11:24:14.575555 00:15:5d:02:0a:16 > Broadcast, ethertype IPv4 (0x0800), length 374: (tos 0xc0, ttl 64, id 10348, offset 0, flags [none], p                                                                                                   roto UDP (17), length 360)
    172.17.17.82.bootps > 255.255.255.255.bootpc: [udp sum ok] BOOTP/DHCP, Reply, length 332, xid 0x6783a095, secs 8, Flags [Broadcast] (0                                                                                                   x8000)
          Server-IP 172.17.17.82
          Client-Ethernet-Address 1c:6f:65:83:a0:95
          file "undionly.kpxe"[|bootp]
11:24:22.585346 1c:6f:65:83:a0:95 > Broadcast, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 20, id 2, offset 0, flags [none], proto                                                                                                    UDP (17), length 576)

geardog

While it was discussed that fog may be the issue, talking to Sebastian had me thinking there was some debate.

Here is the clearOS side.
https://www.clearos.com/clearfoundation/social/community/clearos-dnsmasq-seems-to-step-on-other-nextserver-broadcasts

His tcp dump isn’t showing a next server broadcast. I’m feeling like I may have done something wrong. hmm

geardog

Thank you guys. If there is anything I can do to facilitate the big brains, let me know.
George, should I email you the PCAP?

geardog

@sebastian-roth Ah, I’m using clearOS, but I’ve left the tftp line blank, thinking it would be disabled.

I tried pointing it at fog, at one point, but it didn’t seem to behave so I cleared the line.

Just now I entered fog ip in the router’s tftp direction field. The client instead of attempting to boot from fog immediately gives a “media test failure” when trying to pxe boot.

clearOS dhcp.conf (the quotes are surely wrong, but it’s in the api)

Clearing the field again takes me back to the start of the post and gives me the posted error. I’m not seeing anything screwy in the clearOS router, as running.

clearOS dhcp.conf

clearOS dnsmasq.conf

geardog

Fog 1.5.9 on ubu 20.04.1 VM not handling dhcp, using dnsmasq

I feel like the flaw is the tftp:// ip address showing the gateway, but fog settings shows the correct ip of fog.

I’m close to having it up again, but … any help would be great !

fog-service-output.txt

geardog

@sebastian-roth

Thanks for that. I’m using the linked tutorial in the correct context!

Fog 1.5.9 on Ubuntu 18 (sorry) spit back an error on systemctl restart dnsmasq “Bad dhcp-range at line 38” which was caused by including the <> around the IP. wow …