Posts made by Tom Elliott

@falko Imaging will work in your case, I’m just not sure how you can have NFS without having /etc/nfs.conf.

I did the 2 points I’m aware of:
/etc/nfs.conf
/usr/etc/nfs.conf

but I have no idea where your nfs.conf file is

@AUTH-IT-Center Sorry it was staged, but not pushed, it is now, thanks! (For dev-branch)

@falko And it worked?

Now I did add checking to see which file to use, can you tell me what output of:
rpcinfo -p gives you?

@Fog_Newb (This is a copy paste, just easier that way )
I have updated the code for both working-1.6 and dev-branch to revert the changes to port=20048 to commented out.

Moved the code to set the mountd port only by use of an nfs.conf.d directory.

This should prevent the problems of port being set in multiple places on subsequent updates.

I’m sorry, I didn’t realize subsequent updates would cause the below port= items to be set as well cause well I am human sometimes.

@falko I have updated the code for both working-1.6 and dev-branch to revert the changes to port=20048 to commented out.

Moved the code to set the mountd port only by use of an nfs.conf.d directory.

This should prevent the problems of port being set in multiple places on subsequent updates.

@falko That’s interesting.

/etc/nfs.conf is supposed to be the defacto location for the nfs configuration though I suppose it could should up in other places.

https://man7.org/linux/man-pages/man5/nfs.conf.5.html

I suppose I’ll have to be more specific in the calls but it’s okay I have to remove the entry anyway.

Thanks for letting me know.

@Fog_Newb there is a new sed statement that is trying to set the port for mountd to 20048, but seems it may be setting all ports after mountd to 20048. We are aware but trying to figure out why and how to fix.

@sideone Please retry the latest yet again. It seems the changes I made before just didn’t take or were accidentally overwritten from another commit.

@tomas-voboril The hidelist-delete specific woudl not be the value, the value should be

Rulename: SUB_MENULINK-hidelist-deletespecific
Value: list
Parent: menu
Node: image

While the SUB_MENULINK-list could be indicated specifically for images, yes, it really shouldn’t be (though you can just re-add a similar one)

That one is specific to all pages’ ability to list items. At least that was the intent behind it I believe.

@sideone Fixed in latest.

Thanks for reporting.

@sideone Ah, I think I see, okay give me a bit

@sideone I’m only seeing the General tab.

Under Associations you should see location association?

@tomas-voboril said in How to get rid of Delete button under Images section:

Hello @Tom-Elliott,

yes I’m aware of that, this is the current settings we have. Could you please tell me which of those is related to my problem? I’ve already tried to get rid of “SUB_MENULINK-deletemulti” and “SUB_MENULINK-multicast” but the button was still visible.

Thank you,
Tomas

Where did this ‘deletemulti’ come from?

WHile I know there’s a great amount of need to granularize FOG for access controls, this is just not something we’ve had a large enough development effort of.

I understand wanting this to work how you want it, but just adding things without knowledge of how to best approach isn’t going to work.

I ask this because I do not see a hook designed specificall for -deletemulti
now that’s not to say we couldn’t add it but access controls for “menulink” are specifically designed to remove access to the links that give you things.

So if you wanted to hide the list option for the images (where deletemulti exists) you can do that, but you cannot remove individual segments of the page. This, again, does not mean it couldn’t be added but it’s an effort to add new features like this to be as granular as it seems you’d like to be.

If you don’t want the access to delete multi, for now I’d suggest setting the users to not even see the list link.

You can configure a new role to the effect of:
SUB_MENULINK-hidelist-deletespecific list menu image
As the configuration so it’s specific only to image list item.

Of course if you just don’t want the user to delete anything, you already have an option called
SUB_MENULINK-list

Now, this doesn’t get rid of the edit pages ability to delete.

I’m not sure we’ve had such a request to remove individual page tags, but please remember FOG was never really designed to be access-control specific.

It was designed to be a quick method to create and deploy images to vast machines. Not that it is an excuse but it was never built to be a user controlling aspect, though we do understand that it should be a bit.

As we have worked on making FOG far more secure, the user control just hasn’t been a big part of the list.

I will see if I can work to make all the page elements hooked so that the Access Control plugin has more to glob onto, but then we come into an area of what to name it and how to get Access Control to dynamically see all these things (as it would not be able to operate in the fashion it currently is programmed as).

Not saying it couldn’t be done, just it’s very time consuming and the plugin has to be able to manage itself as well, yay more fun!

@fogcloud Specific to your changing tcp 46500, 55000, etc… etc… I think this was due to NFS and RPC-Bind

I have pushed code for dev-branch and working-1.6 (just this morning) that should maintain NFS static port to 20048 which can be both TCP and UDP. At least this way, it’s static.

@AUTH-IT-Center @fogcloud I will work toward firewall-cmd (as that’s the system I’m using - Fedora 40) but the services I have enabled on mine:
(Standard server - I’m working with 1.6 so bare with that as well)

services: ftp, http, https, mountd, nfs, rpc-bind, ssh, tftp # this will often include ports
ports:
{port: 111, protos: udp, tcp} # Portmapper - NFS uses this
{port: 49512-65532, protos: udp} # multicast

if we want ports related to each service:

20, 21 TCP - FTP
22 TCP - SSH
69 UDP - TFTP
80 TCP - HTTP
111 TCP, UDP - PORTMAPPER, RPC-BIND
443 TCP - HTTPS
20048 TCP, UDP - MOUNTD
49512-65532 UDP - MULTICAST (if you really want to get down to it, these should only be even numbered ports as well - to lessen number of open ports)

If you have a dhcp server, I think you’d need:

67-68 UDP

Now to be fair I don’t know if there’s anything else necessary but I think this would cover everything you would be needed. TFTP is only needed for the initial getting of the files during PXE boot so I believe that will always be port 69, no need for the UDP ports (though happy to be corrected if needed.)

@tomas-voboril So looking at the base code it seems this plugin is translating SUB_MENULINK to SUB_MENULINK_DATA (this is fine, just trying to break it down)

It then uses these rules to effectively prevent a role from accessing these things, or so it seems.

By removing the entry as you have here, it seems, to me, that you’ve allowed deleting the thing.

If the user was part of the role that was supposed to have this removed, then i suppose I need more details as and where possible.

Please remember, this is a plugin. While we have included it into the main FOG project code, this is a custom thing and not guaranteed to work from the outset due to changes in the core code.

I will see if and when I can work on testing out what the problem you’re seeing actually is, but if you have any more details that can help us narrow down exactly what we can do to replicate and what’s not working about it, that will help.

@AUTH-IT-Center Thanks for letting me know.

I have created a class method that will do the authorization checks as well (meaning we call one line of code in scripts that need authorization check and its consistent across requests. So if we do have to tweak it later, we only have to adjust it in the one spot.

Thanks @geardog @fogcloud @AUTH-IT-Center For letting us know.

@fogcloud @geardog
Can you guys try dev-branch.

I just pushed what I hope would fix this problem. (Version gathering as well)

@geardog What are the steps (as verbose you can give) that you’re taking to try to export?

@sideone You may have to hard refresh your screen for it to take effect, though it’s also possible what I added just simply didn’t work. Didn’t have a chance to test it for myself. Only just got my dev system slightly back up (and am typing to you right now from it.)

I’m pretty sure it’s the hard refresh issue though.

Try CTRL+SHIFT+R in Google Chrome. (I know, I know, F5 or the refresh button should do it) but it doesn’t. Hard refreshes clear all local app cache for JS in browsers and is a specialized step for the procedure.