Mounting /images/dev Permission Denied



  • Server
    • FOG Version: 1.3.5
    • OS: CentOS 7
    Client
    • Service Version:
    • OS:
    Description

    Attempting to work my way through the creation of a backup solution with a repository of images stored on a Windows server. I have FOG setup on a CentOS 7 VM using VMWare & ESXi. My storage repository is a disk shelf connected into Windows Server 2012. I have a network cable directly connecting ESXi and the Windows server (will be routed through switch later ). NFS Share is setup in Windows Server, and a Virtual Switch opening up the network interface for the FOG Server. I have successfully mounted the NFS Share as a local drive in CentOS 7 as /images. Installed FOG as usual. Install went through without a hitch, .mntcheck in both /images and /images/dev. All permissions seem correct according to CentOS and FOG.
    I am experiencing 2 issues:

    1. When I try to access the Disk Shelf from within Windows I get access denied.

    2. When I attempt to create an image from a workstation I get an error: Mounting /images/dev Permission denied and it reboots in 1 minute.

    Anyone have any suggestions or ideas?


  • Senior Developer

    @vkenny The second element. (Single data store/server, 5 different nodes pointing essentially at the exact same spot.)



  • @Tom-Elliott
    Do I break the Data store up into 5 different data stores in ESXi, or leave it a single Data store and create 5 different storage nodes from the single data store?


  • Senior Developer

    @vkenny Yes. From the VLAN perspective the information remains exactly the same.

    The only problem, as I see it, is your /tftpboot/default.ipxe might have some problems.

    So after the first install you would want to change the /opt/fog/.fogsettings file.

    Edit the ‘ipaddress=’ line to read: ${next-server} where the IP address was. (Literally read ${next-server}) (Though I can help you manually edit the /tftpboot/default.ipxe file as this could also cause other unknown issues.)

    Your DHCP for each vlan would need to point at the respective FOG Server VLAN IP in regards to Option 66/next-server



  • So how are the storage Nodes synced? If I create an image in lets say “Room 1” but want to deploy that image to say “Room 2” will this be possible?


  • Senior Developer

    @vkenny So here’s my thoughts/suggestions, take them as you will.

    Setup a Single server, with 5 nics.

    Install FOG on that server as you normally would.

    Once installed create 4 more storage nodes.

    All nodes will contain exactly the same information with the exception of the Name and IP address of the node.

    This is just my suggestion. Sharing the same disc with 5 different VM’s is going to cause problems, no matter how it’s done.



  • @george1421
    Each FOG VM is setup to have access to a specific VLAN through Virtual Switch and Port Group. We have that setup already.


  • Moderator

    @vkenny said in Mounting /images/dev Permission Denied:

    I know the next question is going to be why do you need 5 FOG VM’s. The reason is we have 5 independent networks that cannot be accessed by any other. Each network is on a different VLAN with different IP schema.

    Does your ESXi server have the potential access to all of these vlans?



  • I have removed the remote Windows server from the mix. I have added a PERC into the ESXi server that houses my FOG VM’s and connected the Disk Shelf directly into the ESXi host. Have created the Data Store in ESXi.

    Now I need to make this Data Store available to 5 different FOG VM’s but with access to the entire storage system across all VM’s. I need to have all VM’s able to access all images.

    I know the next question is going to be why do you need 5 FOG VM’s. The reason is we have 5 independent networks that cannot be accessed by any other. Each network is on a different VLAN with different IP schema.

    Does anyone know of a FOG Wiki or otherwise that will assist with making this happen?

    The Windows remote server didn’t work, and ended up being more trouble than it is worth. We gave up and decided to hook the disk shelf directly into the ESXi host.


  • Testers

    What else is the windows server you’re using do?
    Maybe it’s simpler to just change it to a linux server?
    Then using it as a storage node is nice and supported.



  • @Junkhacker yes. poor choice of words on my part. I should have said creation of a “Deployment Solution”.



  • I think i will revert to a snapshot and follow the instructions initially provided by george1421 and see where this gets me. If it doesn’t work, we will perhaps rethink the architecture. Whatever the case, i will attempt to provide details on the procedure we used once we get it up and running.


  • Developer

    @vkenny said in Mounting /images/dev Permission Denied:

    Attempting to work my way through the creation of a backup solution…

    I just want to address this from your first post. Fog is NOT a backup solution. It is a deployment solution. I do not recommend you try to use it for backups.


  • Senior Developer

    @vkenny The statement bothers me, honestly. If your security team is the guys saying: you need to do these things. How is it up to them what time they’re willing to spend to do something.

    I know this isn’t something you’re necessarily going to be able to answer, but think about that statement:

    “Security team sets the parameters that I must follow. They are not going to spend the necessary time to STIG the Linux server.”

    They’re the ones enforcing things? How is it up to them what time is spent to meet their own requirements? I realize you’re trying to follow your policies and procedures. That seems extremely poor decision though. They determine how much effort they’re going to put forward to secure the environment?

    Sorry just my mentality getting the best of me.



  • @Tom-Elliott By all accounts you are correct. Problem is the security team sets parameters that I must follow. They are not going to spend the necessary time to STIG my Linux server and i cannot just do whatever i wish, certain things are set in place, and i must work within.


  • Moderator

    Understand you are not paying me for my service here, so these are only my opinions. Also I’m not throwing rock here either, the goal is to help you to a workable FOG solution.

    I need a Windows server containing the Storage node so, if required, someone with no *nix experience can drop images, software etc… on the storage server.

    This constraint is illogical. The storage for fog being Windows based has no bearing on being able to drop (capture and deploy) images, installing snapins or anything for that matter. The IT Admins interface with FOG using the web gui once FOG is installed. MS Windows in this situation really has no value for image deployment.

    I also need the Windows server where the images are stored to have certain security protocols in place that are only officially approved for Windows. They also have these protocols for REDHAT but the licensing costs required was not approved.

    If you are talking about DHS, STIG or NIST requirements, install FOG on a Centos OS. Centos and RHEL are functionally equivalent operating systems. The protocols and their execution should be nearly identical.

    Further, i need this storage node to provide storage to 5 FOG VM’s. I have an enterprise setup with 5 different VLANs and need a FOG VM for each VLAN, but need the images to be available to all VLANs/FOG VMs.

    Is there a technical reason why you need 5 FOG VMs in this setup? Functionally having 5 VMs using shared storage would consume the same bandwidth as having 1 VM and shared storage. You would consume even less with 1 FOG VM and local storage.

    I am still getting the Permission Denied even though “Everyone” can access the CIFS shared drive… I’m so close yet so far.

    The CIFS option was just an idea, we have not tested this configuration to say it will work or not. I would try to mount the CIFS share from the fog server and see if as root on the FOG server can you touch a file that exists on the CIFS share.

    Time is running out for the network maps and submission of a proof of concept. There has to be a way…

    If you would have followed the guidance I gave you in the very first post. It would have instructed you how to setup windows 2012 as a FOG storage node. Can I say for absolute will it work in your environment? In a word, No. It appears you have some kind of validation / security protocols you must execute. There are no telling what local GPOs would have on restricting access form an external linux server.


  • Senior Developer

    And if you need to test for other OS’:

    http://iase.disa.mil/stigs/os/Pages/index.aspx


  • Senior Developer

    For what it’s worth:

    All of the information for the STIGs can be found:
    http://iase.disa.mil/stigs/os/unix-linux/Pages/index.aspx

    These are able to be downloaded and applied where/as necessary.


  • Senior Developer

    https://myopensourcelife.com/2013/09/08/scap-and-remediation/

    I’m sure this won’t meet all the requirements. But I’ll guarantee this isn’t a “Windows ONLY can do” type thing. So many organizations use Linux in environments. While it may not be “as straightforward” as a person may like does not mean it’s not possible to implement and manage on any system. If it’s possible on RHEL, it’s possible on any version of Linux almost guaranteed. Only if the STIG has requirements for a 3rd party binary will there be a problem. But this, itself, poses a security issue (if it is indeed the case) as you’re making a security system reliant on a 3rd party to provide safe and secure code at a cost. (Sounds like ransomware almost to me if you ask me personally).


  • Senior Developer

    The very basic model of a “windows storage node” would be:

    FTP with fog user/password to the location of the /images equivalent on the windows side.
    NFS exposed for the /images side.

    The basic structure on the Windows server would require:
    /images/.mntcheck (blank file)
    /images/dev/.mntcheck

    I’d also recommend creating the postdownload and postinit scripts:
    /images/postdownloadscripts/fog.postdownload
    /images/dev/postinitscripts/fog.postinit

    The /images should be in “CHMOD 777” (Read, write, execute for everybody)

    The basic contents of fog.postdownload should contain:

    #!/bin/sh
    ## This file serves as a starting point to call your custom postimaging scripts.
    ## <SCRIPTNAME> should be changed to the script you're planning to use.
    ## Syntax of post download scripts are
    #. ${postdownpath}<SCRIPTNAME>
    

    The basic contents of fog.postinit should contain:

    #!/bin/bash
    ## This file serves as a starting point to call your custom pre-imaging/post init loading scripts.
    ## <SCRIPTNAME> should be changed to the script you're planning to use.
    ## Syntax of post init scripts are
    #. ${postinitpath}<SCRIPTNAME>
    

    This will allow customization of your stuff, but you will not “see” this server on the dashboard.

    Basic node information:

    IP Address of the Windows Server
    The path as shared
    The ftppath as shared (likely the same as the original)
    The fog ftp username
    The fog ftp password

    The snapins and ssl paths will be required but won’t truly exist so set these to fake paths if you want.


Log in to reply
 

Looks like your connection to FOG Project was lost, please wait while we try to reconnect.