Ticket #642 (closed enhancement: fixed)
RFE: permissions="inherit"
Reported by: | anonymous | Owned by: | solj |
---|---|---|---|
Priority: | major | Milestone: | Bcfg2 1.2.0 Release |
Component: | bcfg2-client | Version: | 1.0 |
Keywords: | Cc: | [email protected]… |
Description
Rather than store the permissions for a ConfigFile? in the xml file, it would be good for the permissions on the filesystem to be used instead. This would only work for the permissions, not for ownership since the user:group on the remote system may not exist.
Attachments
Change History
comment:2 Changed 14 years ago by anonymous
- Milestone changed from Bcfg2 1.0 Release to Bcfg2 0.9.6.1 (Reporting System Bugfixes)
I'm confused.
Should I be using this:
<ConfigFile? name='/etc/sysconfig/iptables-config' perms="0644" />
which gives the error: /var/lib/bcfg2/Bundler/iptables.xml:3: element ConfigFile?: Schemas validity error : Element 'ConfigFile?', attribute 'perms': The attribute 'perms' is not allowed.
or this:
<Permissions name='/etc/sysconfig/iptables-config' perms="0644" />
which gives the same error: /var/lib/bcfg2/Bundler/iptables.xml:4: element Permissions: Schemas validity error : Element 'Permissions', attribute 'perms': The attribute 'perms' is not allowed.
comment:3 Changed 14 years ago by desai
- Status changed from new to assigned
Bundles only contain <Element name='ename'/>
All other elements come from later in the generation process (either from inside of Cfg, or Rules, depending on the entry). If you have a ConfigFile? entry, its ownership and permissions are specified inside of Cfg in the :info or info.xml file. If you are using Permissions, you need to bind it in Rules and set its attributes there. This will all be cleaned up in 1.0 with the unification of all posix path types.
comment:4 Changed 14 years ago by solj
- Version changed from 0.9.x to 1.0
- Milestone changed from Bcfg2 0.9.6.1 (Reporting System Bugfixes) to Bcfg2 1.0 Release
comment:5 Changed 14 years ago by solj
- Milestone changed from Bcfg2 1.0 Release to POSIX unification
comment:6 Changed 14 years ago by solj
- Milestone changed from POSIX unification to Bcfg2 1.0.1 Release
comment:7 Changed 14 years ago by solj
- Milestone changed from Bcfg2 1.0.1 Release to Bcfg2 1.1.0 Release
comment:8 Changed 13 years ago by solj
Hmm, this seems very limited since you can only specify one set of permissions. How would we handle priorities in this case?
comment:12 Changed 13 years ago by solj
- Milestone changed from Bcfg2 1.1.0 Release to Bcfg2 1.2.0 Release
comment:13 Changed 12 years ago by solj
- Owner changed from desai to solj
- Status changed from assigned to accepted
comment:14 Changed 12 years ago by solj
- Status changed from accepted to closed
- Resolution set to fixed
Added in 19586bc42aa90543cf27e33ec32bd7df222138e8.
s/on the remote system may not exist/on the remote system may not exist on the bcfg2 server/