Categories

  • 13k Topics
    114k Posts
    K

    @Tom-Elliott
    Automatic snap-ins (connected to the group or the PC) don’t always work well, e.g., when the PC is busy with itself and the Microsoft ecosystem after cloning. For example: the PC isn’t ready for the snap-in yet because it’s currently installing an update, isn’t in the domain yet, etc.
    That’s why, over the years, I’ve gotten into the habit of first checking whether the PC is in the domain, letting it boot up completely, and only then running my “one” snap-in per PC. In that single Snap-in, I gather everything I need to set up the PC: for example, a student PC needs a Veyon client, the student proxy server, etc. => Student Snap-in; a teacher PC needs the Veyon Master and the fast teacher proxy => a separate Snap-in for teacher PCs

  • Get the latest news on what's happening.
    184 Topics
    825 Posts
    A

    @Tom-Elliott I really appreciate that you are putting effort into providing more frequent releases, which makes it easier for everyone to deploy new security fixes in time. Keep up the good work!

  • View tutorials or talk about FOG in general.
    2k Topics
    19k Posts
    V

    Hello everyone,

    I am facing an issue with image capturing after performing an upgrade on my FOG server from 1.5.10 to 1.5.10.1886. Before the update, everything worked fine for me. The images were stored directly on the Synology NAS.

    My Setup:

    FOG Server: IP 192.168.10.220 (Debian 13) Storage: External Synology NAS with multiple virtual IPs (192.168.109.220 and 192.168.110.220). Storage Configuration: The Synology NAS is configured in FOG web UI as the Master Node for its storage group. The local Default storage node is NOT the master. Clients: Multiple clients on different subnets (e.g., 192.168.109.23 and 192.168.110.23).

    The Problem:
    The Partclone phase finishes successfully on the client machine. The image files are correctly uploaded via NFS directly to the Synology NAS into the /images/dev/[MAC_ADDRESS] folder.

    However, right after Partclone reaches 100%, the task gets stuck in the FOG Web UI (at around 70%), and the client screen shows the following PHP FTP error:

    Error returned: Type: 2, File: /var/www/html/fog/lib/fog/fogftp.class.php, Line: 709, Message: ftp_put(/images/dev/[MAC]): Failed to open stream: No such file or directory, Host: 192.168.110.220, Username: foguser

    What I have verified:

    I tested the FTP connection manually via CMD/PowerShell from a PC using the same foguser credentials. I am able to log in, mkdir, rename, and rmdir inside the /images and /images/dev directories on the NAS without any permission errors. If I move and rename the MAC folder manually inside Synology File Station from /images/dev/[MAC] to /images/[Image_Name], the image works fine. This setup worked flawlessly before the FOG server upgrade. The /images directory is NOT mounted locally on the FOG server itself (and never had to be). Verified FTP username and password on NAS and FOG. It's same.

    It seems that fogftp.class.php is incorrectly triggering ftp_put (trying to read a local file from the FOG server) instead of doing a remote ftp_rename directly on the NAS storage node.

    Has anyone encountered this bug after a recent upgrade, or is there a specific setting in the new version that I missed?

    Thank you for any help.

    Storage Node for NAS
    Storage Node for NAS.png

    Error on PC
    U10-PC13.jpg

  • Report bugs, request features, or get the latest progress.
    2k Topics
    21k Posts
    K

    @Valer Hi Valer,

    You can see my tutorial on using Secure boot with Shim, and my thoughts on what 2.0 means for Secure Boot with FOG here: http://forums.fogproject.org/post/158170

105

Online

12.7k

Users

17.6k

Topics

156.7k

Posts