<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">2014-06-12 2:14 GMT+02:00 Adam Williamson <span dir="ltr">&lt;<a href="mailto:awilliam@redhat.com" target="_blank">awilliam@redhat.com</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
&quot;Should kickstart firewall options conflict with the settings that would<br>
otherwise result from a deployed server role, the kickstart options must<br>
take precedence.&quot;<br>
<br>
that seems to make sense to me</blockquote><div><br></div><div>Yes, assuming you are talking about an explicit kickstart “role deploy” command and kickstart “firewall” command.  Within %post and post-install actions, simply the last edit should win, whether it is a manual command or a role deploy.<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Note that this is *not currently the case*. anaconda does not have any<br>
remote auth configuration support of which I&#39;m aware at present.</blockquote><div><a href="https://fedoraproject.org/wiki/Anaconda/Kickstart#realm">https://fedoraproject.org/wiki/Anaconda/Kickstart#realm</a> ?  (Possibly in combination with <a href="https://fedoraproject.org/wiki/Anaconda/Kickstart#auth_or_authconfig">https://fedoraproject.org/wiki/Anaconda/Kickstart#auth_or_authconfig</a> , I’m not sure.)<br>
</div></div>   Mirek<br></div></div>