Mounting /images/dev Permission Denied
-
@george1421
since I’m so close at this point, do you have any ideas on my previous post before I burn everything down and start over with your proof of concept… -
@vkenny What’s in the installers error log in regards to the setting up storage failed.
-
error log:
chmod: changing permissions of ‘/images’: Permission denied
chown: changing ownership of ‘/images’: Permission denied -
@vkenny This might be because of how you’re sharing. You haven’t done anything wrong, but it’s shared from another element.
Try running the installer with the
-Xargument. -
ran it with -X and it bypassed the storage setup which indicates failed when script is running. The /images directory still does not have the correct permissions.
what’s more is when I try to chmod or chown the /images directory I get permission denied even though I’m root, and the user used to mount cifs in fstab is in the administrators group in windows with full control.
-
@vkenny THis is because it’s shared from a windows source. Permissions must be set at the windows side, not the linux side.
-
Maybe I’m missing something, but why don’t you just add the NFS share of Windows directly as a storage option? I don’t really see the point in the reexporting, particularily because it doesn’t work by default afaik.
-
It doesn’t work by default, not only as far as you (or I) can tell, but it obviously isn’t working anyway.
@vkenny Can you just take what you’re trying to get “Windows” to do an place it on the actual FOG Server?
I don’t understand why you’re wanting this on a Windows machine. FOG doesn’t run, natively on a windows machine. So you already have a FOG Server. Why not (as @quazz suggested) take this particular “storage” and put it directly on the FOG Server?
Nothing we’ve done has worked and has been more a waste of time than it would’ve taken to have started by placing it directly on the server as it’s own storage element.
-
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.
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.
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.
I am still getting the Permission Denied even though “Everyone” can access the CIFS shared drive… I’m so close yet so far.
Time is running out for the network maps and submission of a proof of concept. There has to be a way…
-
@vkenny So, add the NFS info of the Windows Server to the FOG VM as storage node.
And then maybe you have to change permissions, but that should be it, as has been said by 3 different people so far.
-
@vkenny What “security” protocols are you requiring that “only windows” can apply?
-
Awesome!! How do i change these permissions, and what shall i change them to?
I thought if i have “Everyone” (In Windows) to be able to access the CIFS and have the fog user as an admin this would rectify the permission issue.
-
@Tom-Elliott DISA STIG
-
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/.mntcheckI’d also recommend creating the postdownload and postinit scripts:
/images/postdownloadscripts/fog.postdownload
/images/dev/postinitscripts/fog.postinitThe
/imagesshould 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 passwordThe snapins and ssl paths will be required but won’t truly exist so set these to fake paths if you want.
-
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).
-
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.aspxThese are able to be downloaded and applied where/as necessary.
-
And if you need to test for other OS’:
-
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
toucha 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.
-
@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.
-
@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.
