Best posts made by Tom Elliott

https://news.fogproject.org/fog-1-3-5-and-client-0-11-11-officially-released/

https://news.fogproject.org/fog-1-5-0-rc-11/

I know I’ve been out of this for a little bit. I check in here or there, but just been extremely busy.

I don’t want to stop contributing, I just am taking time for myself after my workly duties.

I have to give a big gratitude and thanks for everyone here trying to help out whether by code, by helping the rest of the community, or documentation.

@Sebastian-Roth I know you’re busy but you’ve kept the project rolling even with the minimal availability you have. Thank you.
@george1421 I’m sure you’re busy, but I still see you posting and helping where possible and amenible. Thank you.
@Wayne-Workman I know you’re helping where you can as well. (Of course I can’t exactly post everybody because I’ve been busy and honestly not keeping up with the forums as much as I probably should.)

@everyone Thank you. Thank you for still believing in this project. We’re doing the best with what we have. Please understand in we’re lacking, it’s most likely unintentional. I know I’m just busy.

TLDR; Rerun the fog installer if you have lost “Database Connectivity” to your fog server, or run the ALTER USER syntax shown below.

So Ubuntu 16, among others I suppose, enable a “security updates” to be applied automatically as a “default” to things. Why, well it makes it simpler to ensure your Ubuntu systems are in compliance and patched for any potential exploits. This causes unknown and unexpected issues.

I figured it’d be a safe thing to express that there could be problems (as many of you have already experienced) that when these updates go up (with or without your knowledge) it can break functionality in unexpected and inopportune ways.

The quickest fix is to simply rerun the fog installer which should correct the problem.

As a note, it seems this problem is specific only when the mysql account is the 'root' user AND the password is blank.

The “fix” if you must do it manually is to open a terminal and obtain root:
Super (Windows Key) + T then sudo -i (in most cases).

From there, open mysql with mysql -u root

NOTE: MySQL MUST be run with ROOT.

Run:

ALTER USER 'root'@'127.0.0.1' IDENTIFIED WITH mysql_native_password BY ''; AND
ALTER USER 'root'@'localhost' IDENTIFIED WITH mysql_native_password BY '';

It’s okay if one of them fails. This is going to fix Most people’s issues.

I would highly recommend removing the unattended-upgrades as many of these “sudden” issues came as a security patch ubuntu pushed out. By default Ubuntu typically set’s this for you as enabled and it can cause havoc on you as you (the admin) may not have “done” anything.

To prevent this problem from happening in the future you could run:

apt-get -y remove unattended-upgrades (AS Root again).

FOG is still actively being developed. It’s not necessarily readily apparent, but we can assure you things are still being worked on. These updates may not be communicated in a way that everybody just knows, but can easily be seen if one were to look at our repository site.

Between our own schedules and lives, we can get very busy. We try to keep things updated and help out on the forums even during lull periods. This might mean we aren’t pushing an RC or release as frequently. It may mean we’re working on other things for the project, such as can be seen if looking at our github site.

Our forums are heavily active, and this should point as an indicator to our “status” as well.

If anybody would like to see an increase in developers donating their time to making this free software, consider donating either with monetary support or by spending personal time to help with development.

FOG is an open source project - it’s even in the name. It is driven by people donating their time and resources. The releases of FOG revolve around when developers can spare a few hours throughout the week. Sometimes that will mean releases will be further, sometimes that will mean releases will be faster. That’s just the nature of our project, and many other open source projects.

Hey everybody,

I know you see me here on occasion from time to time. Life decisions have made it more difficult for me to do things I would normally be doing. Rest assured, I am still around, and while I’m not quite as active as I was in the past, it’s not because I don’t want to be.

I had to move, and as part of that I have none of my normal development stuff readily available. Part of the move made me not have a laptop, until today.

I need to setup my dev environment again, so it may take a little bit, but I will be back up.

That’s correct. The main reason fog is constantly moving forward is because the codebase is improved upon. Major bugs tend to be addressed for the next release. We don’t do an LTS because there’s really two main people working on fog in a consistent manor. Those two are @Joe-Schmitt and myself. Debian and Libreoffice have the team too be able to perform such a feat. Their product is Opensource but they have an employment team which can afford them that luxury. FOG has a team but we make no money and as such are required to work full time jobs. We work on FOG in our free time. I’ve had the ability to even work on it from work because we used the software.

Maintaining many different versions is difficult. And we don’t have a support team. WYSIWYG and I think we’ve done pretty well on support, even if we don’t have the ability to do dedicated support for our product. 1.5 was a major step toward modernizing the GUI. 1.6 will vastly improve on this. It was only recently we kind of came up with a road map on how best to proceed. Of note, 1.5 will be maintained until 1.6 is released. 1.6 is focused on making he GUI much more modern. 1.7 will be focused mostly toward fixing and refactoring the FOG client. 1.8 will focus on making the FOS system more modular and usable. I don’t know yet for 1.9. 2.0 will bridge the gap for our rewrite based on the work from 1.5 and up. While we do plan to try to do backports where possible, it’s much easier to ask people to update to the latest version than it is to try to maintain many different versions with backports in mind. At least for what FOG does.

I doubt this will appease anybody, but it’s what I think needs to be said. We are working hard and provide support for our product as best we can. The community makes fogs support system, I think, one of the best around. Add to that and you can almost always have a developer working side by side to help and fix issues as they come up, I don’t think it’s unfair to ask users to update to a specific version. Even if there are bugs, we will always try to correct what we can, when we can. (And normally it’s a pretty quick turn around).

I’m not perfect and I’ll give you that. We don’t even have a test suite to know if things are working as intended. We have to rely on the community and suggestions are great, just understand our answers won’t always be what people want to hear.

https://news.fogproject.org/fog-1-4-0-officially-released/

https://news.fogproject.org/fog-1-4-4-officially-released/

https://news.fogproject.org/fog-1-5-0-rc-12/

https://news.fogproject.org/fog-1-5-3/

Hey all,

I know this probably seems rather random, but this is just a place for me to put some of my scripts during programming for FOG.

While these are specifically setup for my environment, simple edits can make them portable.

If you all want to try your hand on these for your own projects, feel free.

1. Copy to svn
   – All this does is take my files as I have edited them and copies them to my trunk directory for subversion/svn.
   – I call it copytosvn
   – The extra “trunk2” stuff you see is for btsync when that was running.
   – if I call it as copytosvn git it will do the same as for trunk, but to only the git. This was added due to sourceforge being down last year.

#!/bin/bash
dots() {
    local pad=$(printf "%0.1s" "."{1..60})
    printf " * %s%*.*s" "$1" 0 $((60-${#1})) "$pad"
}
errorStat() {
    if [ "$1" != 0 ]; then
        echo "Failed"
        exit 1
    fi
    echo "OK"
}
trunkUpdate() {
    cwd=`pwd`
    if [[ -z $1 || $1 == svn ]]; then
        cd /root/trunk
        dots "Updating SVN Directory"
        /usr/bin/svn update >/dev/null 2>&1
        cd /root/fogproject
    elif [[ $1 == git ]]; then
        dots "Updating GIT Directory"
        cd /root/fogproject
        /usr/bin/git checkout dev-branch >/dev/null 2>&1
        /usr/bin/git pull >/dev/null 2>&1
    fi
    errorStat $?
}
versionUpdate() {
    dots "Updating Version in File"
    trunkver=`git describe --tags | awk -F'-[^0-9]*' '{value=$2+$3+1; print value}'` >/dev/null 2>&1
    sed -i "s/define('FOG_VERSION'.*);/define('FOG_VERSION', '$trunkver');/g" /var/www/fog/lib/fog/system.class.php >/dev/null 2>&1
//g" /var/www/fog/lib/fog/system.class.php >/dev/null 2>&1
    errorStat $?
}
copyFilesToTrunk() {
    dots "Copying files to trunk"
    for filename in `find /var/www/fog -type d`; do
        if [[ -z $1 || $1 == svn ]]; then
            cp -r $filename/* /root/trunk/packages/web/${filename#/var/www/fog} >/dev/null 2>&1
        elif [[ $1 == git ]]; then
            cp -r $filename/* /root/fogproject/packages/web/${filename#/var/www/fog} >/dev/null 2>&1
        fi
    done
    if [[ -z $1 || $1 == svn ]]; then
        rm -rf /root/trunk/packages/web/lib/fog/config.class.php >/dev/null 2>&1
        rm -rf /root/trunk/packages/web/management/other/cache/* >/dev/null 2>&1
        rm -rf /root/trunk/packages/web/management/other/ssl >/dev/null 2>&1
        rm -rf /root/trunk/packages/web/status/injectHosts.php >/dev/null 2>&1
        rm -rf /root/trunk2/* >/dev/null 2>&1
        cp -r /root/trunk/* /root/trunk2/ >/dev/null 2>&1
    elif [[ $1 == git ]]; then
        rm -rf /root/fogproject/packages/web/lib/fog/config.class.php >/dev/null 2>&1
        rm -rf /root/fogproject/packages/web/management/other/cache/* >/dev/null 2>&1
        rm -rf /root/fogproject/packages/web/management/other/ssl >/dev/null 2>&1
        rm -rf /root/fogproject/packages/web/status/injectHosts.php >/dev/null 2>&1
        rm -rf /root/trunk2/* >/dev/null 2>&1
        cp -r /root/fogproject/* /root/trunk2/ >/dev/null 2>&1
    fi
    errorStat $?
}
makefogtar() {
    dots "Creating FOG Tar File"
    rm -rf /opt/fog_trunk
    if [[ -z $1 || $1 == svn ]]; then
        cp -r /root/trunk /opt/fog_trunk
        find /opt/fog_trunk -name .svn -exec rm -rf {} \; >/dev/null 2>&1
    elif [[ $1 == git ]]; then
        cp -r /root/fogproject /opt/fog_trunk
        find /opt/fog_trunk -name .git -exec rm -rf {} \; >/dev/null 2>&1
    fi
    cd /opt
    tar -cjf /var/www/html/fog_trunk.tar.bz2 fog_trunk
    rm -rf /opt/fog_trunk
    cd $cwd
    unset cwd
    errorStat $?
}
trunkUpdate $1
versionUpdate $1
copyFilesToTrunk $1
makefogtar $1

2. Copy back trunk
   – Copies the file in the trunk folder back to the base folder. Useful if i’m making changes that seem to break things and just need to start fresh, or if something needs to be looked at as its broken, but known working in older version. Allows me to revert the folder and copy back the files in the trunk to the base so I can see things more clearly.
   – Create a backup of your original config.class.php in the root directory.
   – I named it copybacktrunk

#!/bin/bash
rm -rf /var/www/fog;cp -r ~/trunk/packages/web /var/www/fog; cp ~/config.class.php /var/www/fog/lib/fog/config.class.php;chown -R apache:apache /var/www/fog; chown -R 500:apache /var/www/fog/service/ipxe

https://news.fogproject.org/fog-1-3-5-rc-11/

I need people to test it and report please. A lot of work has gone into resizing and waiting to release an RC or Full version until the init’s are “working” seems a bit backward. The point of RC’s is to get the bugs worked out and get users testing things so we have more viable reports. I won’t release 1.3.5 if there’s still work that needs to go into the init scripts, but I should be able to release an RC so I can find out what else needs to be worked on.

https://news.fogproject.org/fog-client-0-11-18-officially-released/

Thank you @Sebastian-Roth

@george1421 and that “something” is called S99fog

Hey everybody,

I’ve decided to publish the init’s I’ve been working/sitting on since before Christmas. With these init’s come, I think, a ton of improvements in how to handle Partitions. There’s minimal assumptive (as I call it) code for handling the generation of partitions. The minimal part is only left in for the compatibility of old images. Everything else should be very much generic and operational.

I’ve tried testing all possibilities, but I try and try and always seem to miss something.

Please let us know if the new init’s are causing issues?

Thank you,

Left blank purposely as news site is not working.

Once the news site is updated and working we’ll update this with the link. This is more or less to let people know it is currently available.

Why do I use fog? Well, for me, it started with me trying to learn more about linux way back in 2007-ish. I saw a posting on howtoforge.org and decided, why not. https://www.howtoforge.com/installing-fog-computer-imaging-solution-on-fedora8 (this was the posting although it was much different looking way back then.)

I had been playing with Linux (itself) for many years earlier, but found a need for FOG for where I worked. I was in the Army back then. When I first got to my duty station, the team was imaging computers using a CD which contained an image created by GHOST. I had learned about PXE in my own training and decided to try building a PXE Server to image more systems at the same time as in one months time (before I arrived) the number of systems imaged was about 100 out of an estimated 900 that had to be completed. After building the PXE server and setting up a GHOST multicast session we completed about 300 in one day.

Because of that, I kept forward on PXE booting and the sort of technologies that used it. That’s when I decided to install fog. It was not for the military as we had already had an established system for imaging at that point (through working with our post networking offices). I installed just for my own playing and testing and understanding.

I didn’t know of other items that ran similarly. I loved the fact that FOG used PXE booting, did not require a CD to host the original image, and was completely web managed. I kept my personal systems updated as things came out and did a lot of reading over the years. I knew of other “similar” software’s and decided none of them were as “cool” as FOG was. So I just kept with fog.

Where I work currently, I believe the need was because the items they had were very pricy and people were left to “make” their own images. When I started working here, I noticed the shift of technology moving from MBR to EFI based booting (BIOS vs. EFI if you will), and I new 0.33b was being worked on. However it was completely “stuck” if you will. I slowly decided to work on it, and it’s become what you see now (particularly in trunk).

What is FOG? FOG kind of models itself (now) to what Clonezilla does (albeit with a lot more – I think – improvements). That’s as far as FOG and Clonezilla compare, they use the same type of software to capture the image (now). With enough knowledge and understanding, Clonezilla could easily do what FOG does in whole, but it’s main purpose is to be a disk cloning tool. FOG is primarily designed to be a disk cloning or imaging tool. What does this mean? Clonezilla is great at getting and applying a disk to an equivalent disk (size in specifics) where FOG is designed for imaging in either scenario.

What is Imaging/Cloning? What I consider the difference between imaging vs. cloning is cloning mean’s a one for one copy. The image will be copied from one drive and must (Maybe should is more appropriate?) be placed on an equivalent drive or larger. I consider imaging meaning it captures the software layers of the device, and replaces it similar to cloning, but they need not be placed on the same drive. FOG enables users to make a choice on how they want the data stored and/or replaced. Most IT personnel will likely put imaging or cloning in the same category.

Why FOG? Well I enjoy it. I get to help MANY people around the world and see my own experience and knowledge grow as I find/test/see new technologies. I love the coding as it helps me maintain focus rather than dwelling on anxiety that I experience normally. I love seeing people see what FOG has become.

Why Clonezilla? Can be used for imaging anything so long as the restoration is occurring on matched or larger medium. I personally find Clonezilla cumbersome to initiate, but it does work very well and can be used without requiring network at all. It’s a great software that works well for “disk to disk” clones and scales fairly well if all systems in an organization is the same.

Why MDT/WDS? These paired (from what I hear) are awesome together in that you can do as @george1421 stated about making images from an unattended model with ease as well as capturing and applying that image to many systems. These are also free, but there are limitations.

As with all software, there’s going to be pro’s and con’s. I’m not trying to dish those things out at all.

Of course I’m going to be biased (now) to FOG as it’s more or less been my baby for the last 3 years. What a person uses is totally up to them. You’re going to get biased answers no matter what forum you go to. Especially if you ask on the relative software forum pages. Asking a community like Spiceworks may give less biased information (or maybe multiple biased points of view).

Of note for this, while we wait.

Fixes include WOL issues which will now, and properly, WOL from storage nodes.
IPXE binaries have been updated to start up with a 10 second delay (and informative message first so people don’t think something is hung). This 10 second delay should help with some systems that take a bit for the link to come up.
Group taskings only worked for imaging types only which was accidental. This is now fixed and should work properly.
Proxy information was not working properly and seems to work for RC 14.
Fixes the init.d mysqld init script getting a comment in some Distributions of redhat. This was unknown but figured out and fixed for latest. This was originally thought to be a repository issue but it was not.
Fixes a bit of Arch installation problems.
Fixes Fedora 24 not being able to be installed for some reason or other.

Build buildroot
– Copies the files from the main trunk directory of a remote system (my dev box) and places the files where needed.
– Does require pre-environment setup (config files etc… already in place.
– I call it buildBuildroot
– Copies the init’s back to my other servers as needed.

#!/bin/bash
arguments="$*"
dots() {
    local pad=$(printf "%0.1s" "."{1..60})
    printf " * %s%*.*s" "$1" 0 $((60-${#1})) "$pad"
}
errorStat() {
    local status=$1
    if [[ $status != 0 ]]; then
        echo "Failed"
        return 1
    fi
    echo "Done"
    return 0
}
getCustomBuildroot() {
    dots "Copying customized 64 bit init files"
    scp -rP 10002 mastaweb:/root/trunk/src/buildroot/* /root/buildroot/ >/dev/null 2>&1
    errorStat $?
    dots "Copying customized 32 bit init files"
    scp -rP 10002 mastaweb:/root/trunk/src/buildroot/* /root/32build/buildroot/ >/dev/null 2>&1
    errorStat $?
}
build64bit() {
    dots "Moving to 64 bit build environment"
    if [[ -d /root/buildroot ]]; then
        cd /root/buildroot
    fi
    errorStat $?
    [[ $? != 0 ]] && exit 1
    dots "Removing fog build directory to start fresh"
    if [[ -d "/root/buildroot/output/build/fog-1" ]]; then
        rm -rf "/root/buildroot/output/build/fog-1" >/dev/null 2>&1
    fi
    errorStat $?
    [[ $? != 0 ]] && exit 1
    dots "Building 64 bit inits"
    make -j $(nproc) >/root/buildroot/buildroot64.log 2>&1
    errorStat $?
    [[ $? != 0 ]] && exit 1
    dots "Copying 64 bit inits to remotes"
    scp output/images/rootfs.ext2.xz ubuntu64:/var/www/fog/service/ipxe/init.xz >/dev/null 2>&1 && \
    scp -P 10002 output/images/rootfs.ext2.xz mastaweb:/var/www/html/init.xz >/dev/null 2>&1 && \
    scp -P 10008 output/images/rootfs.ext2.xz fogstorage:/var/www/html/fog/service/ipxe/init.xz >/dev/null 2>&1
    errorStat $?
}
build32bit() {
    dots "Moving to 32 bit build environment"
    if [[ -d /root/32build/buildroot ]]; then
        cd /root/32build/buildroot >/dev/null 2>&1
    fi
    errorStat $?
    [[ $? != 0 ]] && exit 1
    dots "Removing fog build directory to start fresh"
    if [[ -d "/root/32build/buildroot/output/build/fog-1" ]]; then
        rm -rf "/root/32build/buildroot/output/build/fog-1" >/dev/null 2>&1
    fi
    errorStat $?
    [[ $? != 0 ]] && exit 1
    dots "Building 32 bit inits"
    make -j $(nproc) ARCH=i486 >/root/32build/buildroot/buildroot32.log 2>&1
    errorStat $?
    [[ $? != 0 ]] && exit 1
    dots "Copying 32 bit inits to remotes"
    scp output/images/rootfs.ext2.xz ubuntu64:/var/www/fog/service/ipxe/init_32.xz >/dev/null 2>&1 && \
    scp -P 10002 output/images/rootfs.ext2.xz mastaweb:/var/www/html/init_32.xz >/dev/null 2>&1 && \
    scp -P 10008 output/images/rootfs.ext2.xz fogstorage:/var/www/html/fog/service/ipxe/init_32.xz >/dev/null 2>&1
    errorStat $?
}
if [[ $arguments == +(*'customfiles'*) ]]; then
    getCustomBuildroot
    exit
fi
getCustomBuildroot
build64bit
build32bit