Posts made by Tom Elliott

@AUTH-IT-Center I think, at least with what limitations I have this would work just fine in working-1.6

Except you’d be setting the groupNameAttr = edupersonentitlement

My filter query is built as such:

(&(|(%s=%s))(|(%s=%s)(%s=%s=%s)(%s=%s)))

basically it builds it out as:
<group name attribute>=<groups to associate> (and broken into multiple if and as necessary)
<group member attribute>=<userDN>
<group member attribute>=<user name attribute>=<username>
<user name attribute>=<username>

This is built as an AND or (and) or

So in psuedo code:

if (groupNameAttr = <value> or .... or ... or)

AND 

if (groupMember = <userDN> or groupMember = userName = <user> or userName = <user>)

then it should work.
I don’t have a way to represent it, Just saying I think we are covering those basis in working-1.6 (among many other potentials).

@AUTH-IT-Center In my testing with an openldap (ldap.forumsys.com)
https://www.forumsys.com/2022/05/10/online-ldap-test-server/

I wasn’t able to use member/memberof though I wasn’t able to figure out quite why, but when I changed the group member to ‘uniquemember’ all seemed to work.

Assuming eduPersonEntitlement has the uids (in dn format) of the user (either full dn or partial) and it’s directly associated with the ou structure for your admin group:

Similarly your ‘admingroup’ (I know you’ve masked it) but do you have a group in your LDAP that has a full name of: https://entitlements.it.auth.gr/<adminGroupName>?

Now I’m not sure on the exact setup differences (I just helped get the plugin built)

In my experience:
Search base DN tells us where it’s going to search for users
Group base DN tells us where it’s going to search for groups

So if Groups are all under the OU=People,O=Auth,C=GR then this would work, but if groups are not all under OU?

In my example structure my layout was:

LDAP Server -> ldap.forumsys.com
LDAP Server Port -> 389
Use Group Matching (recommended) checked
Search Base DN -> dc=example,dc=com
Group Search DN -> dc=example,dc=com
Administrator Group -> mathematicians
Non-Administrator Group ->
Username Attribute -> uid
Group Name Attribute -> ou #Working-1.6 has this element
Group Member Attribute -> uniquemember
Search Scope -> Subtree and Below
Bind DN -> cn=read-only-admin,dc=example,dc=com
Bind Password -> password

Of course I don’t expect anyone to actually use this setup and this is for testing, not for real login, but gave me a way to test things.

Search Base DN = Where we search for users
Group Search DN = Where we search for groups
Admin/user Group = What groups should users belong in (must reside in the Group Search DN to work.)
Username Attribute = We all know this one
Group Name Attribute = This is new to working-1.6 of course but similar to username attribute. In your case this would be defaulted to name in dev-branch
Group Member Attribute = which attribute stores users that are associated to the group.
Search Scope = Base = Only at the search base, Subtree = Only at the group below the search base, Subtree and below = Everthing from the group base and below. (this is just how I imagine and envision it, if anyone has better descriptions feel free to correct me please.)

Bind DN (what user dn is to authenticate intially with the ldap)
Bind Password (what password to authenticate with)

I know I was explicit but this is what worked for me in my testing.

@AUTH-IT-Center After some pretty serious testing I think I finally got the ldap plugin working on 1.6 as well.

I can make the suggested changes in dev-branch, but that might remove your PR. I can merge yours in, then refactor it so at least you get the due credit, I just refined it to make it more robust?

Hopefully that will help.

your uid=… method it’s not perfect.

Your filter should be:

<groupNameAttribute=<group1>, etc…<groupMemberAttribute=<userdn/or uid information>

So group name I think was always expected to be name for some period of time, though has been refactored to allow

The purpose of the groupMemAttr is the member attribute, not the group name attribute (which I think is what you’re using it for currently?)

The idea of this is:

check all groups (with name as the key indicator explicitely defined unfortunately in dev-branch) that match the name of . whatever group search you’re doing (admin or user) (This is psuedo code of representation for the filter logic ideals:

if (name = this OR name = that OR name = other) {
    AND (if <userDN> is in the member list of this group) {
        This is the access level
    }
}

Your method is saying:

if (member = this OR member = that) { // Here you're using member but using the group name attribute to select it?
    AND (if usernameattribute == username) { // this would be true if the bind already read worked.
    }
}

Basically the problem with your current filter is you only check if the group exists and the username = username, not that the username actually is a member of that group.

We do have logic, I think that double checks but I hope you can see the issue here?

@AUTH-IT-Center I’m asking about testing working-1.6 lol selfishly. Keep using what you’ve done though I did find I think 1 issue in your code (a place where admingroups should be usergroups)

@AUTH-IT-Center I’ve put in a few notes and going to push some code to how I’m doing similar in working-1.6 (though testing of this would be really nice if you happen to get a chance?)

Thank you!

@TimBr Did you migrate this from an older server?

The getPrimaryGroup/getStorageGroup’s are the indicator of the problem here.

Basically, you would likely see the same type of problem if you were to goto snapins:

Effectively the issue is the Image (in this instance) is associated to a StorageGroup that simply doesn’t exist or that storage group has no storage nodes associated to it.

@alexamore90 said in Snapin question:

@Tom-Elliott
yes sure, I would be interested in running a batch file after the fog has restarted because the deployment on the client has finished. I think I can’t use the snapin because of the host registration that we don’t do. but is the postinit done with fog?

You still haven’t answered the question.

I already stated that postinit scripts run in FOS (fog adjacent if you will) but you haven’t answered the question of “where or when” you’re expecting the script to run.

Please provide details of what you’re doing, when you’re expecting things to happen (explicitly as possible) and we can try to give guidance and direction.

Otherwise we’re talking in circles.

@alexamore90 Can you provide more clarification?

“Immediately after deploy” as in after the imaging has completed, but is still in the FOS system?

“Immediately after deploy” as in after the imaging has completed, restarted and is in whatever operating system?

If it’s the first, there’s something called postinit scripts which can do what you may require. There isn’t one that we can provide, you’d have to create and have it run.

If it’s the second, that could be done with a snapin and the machine has the FOG Client, but that would require you to have the machine registered (so no it wouldn’t be possible to run the snapin without registering or associating the hosts to a group)

If it’s the second, and your “golden image” is sysprepped, this is effectively the point of the setupcomplete.cmd script methods. But again you’re left to your own devices here.

@tomierna Glad I could help and glad your issue is fixed.

@tomierna From the snapins there’s a method of associating the snapin to a group.

I think the table in mysql that manages that is:

snapinGroupAssoc

And snapinAssoc is the table that shows which hosts the snapins are associated with.

@tomierna There’s no known issues because of the php 8.3, but rather it’s because your Install seems to not know about a storage group/storage node on the server at the moment?

Can you look and make sure snapins that are associated to this host (or any snapin for that matter) have the new storage group/node associated to them?

@tomierna We’ve been seeing more and more spam lately, so we tried adding things to help prevent it a bit more and more.

@shatchett0 what is the format of the drives?

The formats we do accept for resize:

Ext (2/3/4)
Btrfs
Ntfs
Fat
Xfs

If it’s not got any of those types of partitions, of course it won’t be able to capture them.

@t-schuurmans Sorry to give links after links but i think it’s worth while for you to review and learn as we go along too.

https://forums.fogproject.org/topic/9463/fog-postinit-scripts-before-the-magic-begins

The long and short of it however would be to edit the file:
/images/dev/fog.postinit and add the line:

As I don’t have enough information to narrow it down to just this machine please understand this is a “hack” specific to this one use case:

rm -rf /dev/md0
ln -sf /dev/md127 /dev/md0

@t-schuurmans Did you set the host args to mdraid=true AND the drive to /dev/md127?

There is another post where you may need to create a symbolic link from /dev/md0 -> /dev/md127

Let me see if I can find out that.

I believe that is talked about here:
https://forums.fogproject.org/topic/17257/problem-capturing-right-host-primary-disk-with-intel-vroc-raid1/2

@t-schuurmans https://forums.fogproject.org/topic/17626/issues-with-capturing-an-image-with-a-raid0-array

Might help? From last I could tell at least it seemed things were working. I don’t know though.

Raid imaging support isn’t really baked in as nicely as it probably coudl be (though I imagine it’d be nearly impossible for any system to do so accurately 100% of the time.)

@sega I think that’s where I’m confused.

ALl FOG does is start a software that sends packets. How those packets traverse your network is independent of that (from what I can tell).

Layer 2/Layer 3.

I think you’d want to look into something IGMP Snooping or something for V2 functionality?

@sega https://www.udpcast.linux.lu/hints.html

I think this may tell you more?

We don’t control what “version” your switches can/cannot allow?

@gribbler Based on what I can only guess is a question unrelated to FOS itself:

FOG doesn’t do anything related to fstab on any host.

So this tells me what you’re seeing is completely seperate and most likely the drive booting into normal operating system of which is using xfs filesystm.

Please make a backup of your init.xz/bzImage files and download these specific files:

cp /var/www/fog/service/ipxe/bzImage{,_backup}
cp /var/www/fog/service/ipxe/init.xz{,_backup}
wget -O /var/www/fog/service/ipxe/bzImage https://github.com/fogproject/fos/releases/latest/download/bzImage
wget -O /var/www/fog/service/ipxe/init.xz https://github.com/fogproject/fos/releases/latest/download/init.xz

Then try loading fog?

If you can also capture a video of the whole process and post it somewhere we can try to get to it?

@rogalskij so it seems your “ipaddress” is defined as your fqdn either on the IP address for the storage node directly.

I don’t know what your storage node settings look like but should be looked at likely from:

Storage Node-> DefaultMember

HOpefully that will help.

Normally if you can dereference the DNS name all would be fine so I’m just not sure where to help out.

But at least you know what is happening now?

Thank you for letting us know.