I am intrigued as to why i can’t use the boot pool for Active Directory, its not something i really want to have on a data pool that might be exported…
any idea why the restriction exists?
any way to tweak around it?
This should answer most or all of your questions.
If it does not, simply respond and ask it / them.
1 Like
that doesn’t answer the question in anyway whatsoever, i guess you didn’t actually read the question, or think about it?
I didn’t ask why do i need to dedicate a drive to booting
I asked why the active directory service can’t store its data on that dedicated drive
e.g. why it can’t be stored in boot-pool/.system/somepath given this is is where all the smaba / nfs / and other service data / service databases is stored. AD is a core system service, not ‘data’, it should not be on a data pool, it should be on a system pool otherwise it restricts what can and can’t be done on the system by tying it to an arbitrary data pool that could be exported, sent, whatever.
would you like to take the question seriously and try again at being helpful this time, your post smacks of a condescending attitude…
If I had to guess, something about encryption since boot drive can’t be encrypted on Scale?
Otherwise, no clue.
Your argument for AD being on the boot pool makes sense & I never knew it wasn’t.
1 Like
You should make this a Feature Request, it may get a lot of traction, but I don’t use AD so I’m fairly ignorant in this area. This is going to be the only good way to ask the developers to see what technical reason there is. It could be an Enterprise requirement.
Your question was taken seriously, you were given a serious answer, and @Arwen was polite, not condescending.
2 Likes
Thanks, i wanted to understand the reasoning before i put a feature request in, i know the team has limited bandwidth for the changes. I will do a little more research and then file a jira ticket.
you sure about that, the reply was a cut and paste answer to a different question that then told me to go read an irrelevant thread and reply to that linked and irrelevant thread to get an answer to my question
It might have been polite in their head, it wasn’t received that way given it was utterly useless answer implying to me to eff off and read the manual / search the forum (which i had done both too)
This has more to do with our HA product than anything else. In that case the system dataset always resides on the data pool and so AD state moves between storage controllers. I don’t anticipate us making changes any time soon for the stable product, but maybe in a future release we can consider it. Generally in enterprise people aren’t exporting / importing pools regularly (or rebooting servers for that matter).
3 Likes
It was a very polite way to say what they really think but were too polite to say it straight into your face: “Nobody in the enterprise environment cares! This will never be implemented! Issuing a Jira ticket is a wast of your and ixSystems time”
If you read that linked post, I think it becomes pretty clear why you should not put in any hope into that Jira ticket. Maybe if you read it again, it becomes clear how that thread is not irrelevant to your question.
@scyto - I did not mean to be curt / abrupt about the answer.
What I thought was the case, is that only general config data is stored on the boot pool. During any update, a new dataset is created with the update, and the config copied over, if needed. Any un-supported customizations are lost. So I thought that AD was too complex for that process. Thus, stored in a data pool. I thought the linked post described it.
However, @awalkerix explained in better.
2 Likes
We no longer use Jira for TrueNAS. You would generate a posting with the tag “Feature-Request” and people can read it and vote on it. When you make a post for this, you need to justify the request. What is it solving? How will it improve everyday use? Basically make a case to implementing it, it can’t be “Because I want it” as that will not get many votes.
This voting is a new way for the iXsystems developers to see what people want. Some ideas are no-brainers, some are super easy to incorporate, and some would have the ability to break a lot of other parts of TrueNAS. What sounds easy, may not be easy to implement. That is what @awalkerix is saying.
With all that said, you can still generate a Feature-Request posting because if it is a good idea, then maybe it will be adopted.
1 Like
Just to clarify, we do still use Jira for bug reporting and issue tracking.
1 Like
The point here is that a TrueNAS boot pool is disposable by design.
If whatever Active Directory wants to record is important, and especially if it is NOT saved with the configuration, it should best be in a data pool which will not be removed. Like an application pool.
1 Like
Sorry, i must have misuderstood the last 3T where i thought it was said that Jira was no longer being used. I will need to watch that again.
1 Like
The division of labour between a data pool and the boot pool for this scenario makes no sense to me.
-
the boot pool with the system dataset stores other configuration data about critical items such as samba which is tightly integrated with AD
-
AD data is machine specific, it contains data bound to that machine, if the system data set and boot-pool is lost one will loose the AD config anyway and need to rejoin the domain as the smaba.conf and winbd files are stored in the boot pool dataset not in the system dataset, so having a requirement on the data pool and moving the system dataset to /var/db/system/samba4 does not give a full configuration and more importantly it puts the system dataset on a drive that is designed to be exported to other systems…
-
when adding a data pool i note the system dataset is then moved to that pool, again having that on the data drive means the active directory is now split between two pools.
-
this means that by default to make a data pool exportable and not have it contaminated with machine specific information (the .system data set) the ideal and secure configuration would be:
- boot-pool that stores nothing but OS (think / and /etc and other key files plus the overlay for modified files
- .system pool purely for storing the ,system dataset
- one or more true data pools
Question, is it possible for me to move the .system datapool back to the boot drive (which is a mirrored pair of PLP NVME drives and as such gives me better protection on write consistency than my my data pools)
Yes, this is under System → Advanced → Storage. Expect services that depend on the .system dataset to stop and start.
1 Like
Perfect, thanks, just the solution, i don’t think the requirement to have a data pool should be needed to install AD as all that is needed is the .system dataset to exists (but I cosnider that a VERY low prio fix) as the config is put in .system and that is moved automatically when a data pool comes along - seems a pointless, but ultimately harmless pre-check. It only blocked me until i got some data drives installed.
Moving the pool worked - though interestingly it warned me SMB would be stopped, asked me to verify and the blocked me because the AD service was still enabled - would be nice if it stopped and started the AD service for me too!
@Arwen thanks for taking the time to reply again, i appreciate it.
The answer seems to be as follows:
- the check is pointless as the AD data is store in the .system dataset which already exists on the boot-pool before a data pool is added. And…
- once a data pool is added the .system pool will be moved automatically to the first data pool making the pre-check equally pointless
- the .system pool can be moved back to the boot volume if needed
- the boot volume should be adequately protected irrespective of where the .system data set is store as there is critical config on the boot-pool independent of the .system data set
- irrespective of the .system data set location the boot-pool will need to be backed up to restore a working system, one can’t rely on just backing up the .system pool
tl’dr pointless restriction, easy to work around
I disagree, because critical config is saved in the config backup file.
If it fails, I replace it, reimport the pools, reimport the config from the config backup file.
are you saying you think .system should be stored on a drive with no redundancy/protection, does this mean you move .system from your data pool back to a drive with no protection?
or are you saying you think the boot-pool should not be protected?
if the latter i would much prefer not having to re-install from backup and import config, is there a list of what is and isn’t stored in the config backup file?
–edit–
i just looked, it saves the config database and optionally the secrets, i don’t think all of /etc is saved in the database… though i would need to crack that open to see… there are tweaks i have done that are not backed up in the config - so again i will assert in a production scenario boot-pool cannot be treated as ephemeral and disposable