Mounting /images/dev Permission Denied
-
@george1421 said in Mounting /images/dev Permission Denied:
I did write a proof of concept tutorial for turning a windows server into what fog calls a storage node. ref: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog
Without intending to sound self righteous, my first post outlined what you “could” do to use your windows server as a fog storage node.
-
alright. so I mounted the Windows share as cifs. I can add and remove directories to the mounted share with no issues. I made and deleted directories to assure I was connected.
UUID=ca0220ba-82d7-434f-9231-74ba18706ac1 / ext4 defaults 1 1
UUID=20a99d10-8d99-429c-82b7-4c8655a22d22 swap swap defaults 0 0
//169.254.91.1/FOG-Share /images cifs username=fog_user,password=ThePasswordForFog_User,_netdev,defaults,user,auto,intr 0 0then I ran the fogsetup script again and received this:
-
You still need to install/update your database schema.
-
This can be done by opening a web browser and going to:
-
Press [Enter] key when database is updated/installed.
-
Setting up storage…Failed!
any ideas?
-
-
@george1421 it says at the end of the comments you are at a stand still. Does this work?
ref: https://forums.fogproject.org/topic/6941/windows-server-as-fog-storage-node-proof-of-concept-blog -
@vkenny The standstill was getting the web pages to display correctly. But that is not needed for imaging function, just for reporting to the FOG console. The imaging part should work.
Just understand that was a proof of concept document that was written quite a while ago with a different version of FOG. Will it work today??
-
@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.
