Hello Kevin, I’ve answered at the same time. Take a look at the answer, there’s a command that does everything. It really nails down to avoid running the command. In the xCAT package only runs on the first time:
. /etc/profile.d/xcat.sh if [ "$1" = "1" ]; then #Only if installing for the first time.. $RPM_INSTALL_PREFIX0/sbin/xcatconfig -i else if [ -r "/tmp/xcat/installservice.pid" ]; then mv /tmp/xcat/installservice.pid /var/run/xcat/installservice.pid fi if [ -r "/tmp/xcat/udpservice.pid" ]; then mv /tmp/xcat/udpservice.pid /var/run/xcat/udpservice.pid fi if [ -r "/tmp/xcat/mainservice.pid" ]; then mv /tmp/xcat/mainservice.pid /var/run/xcat/mainservice.pid fi On 26 Sep 2019, at 13:38, Kevin Keane <[email protected]<mailto:[email protected]>> wrote: Just a thought - you could get the best of both worlds by removing this behavior from the RPMs, and creating a separate "setup" RPM that does all these things. This behavior should really be removed from the main RPMs because otherwise, these actions are repeated on updates. _______________________________________________________________________ Kevin Keane | Systems Architect | University of San Diego ITS | [email protected]<mailto:[email protected]> Maher Hall, 192 |5998 Alcalá Park | San Diego, CA 92110-2492 | 619.260.6859 | Text: 760-721-8339 REMEMBER! No one from IT at USD will ever ask to confirm or supply your password. These messages are an attempt to steal your username and password. Please do not reply to, click the links within, or open the attachments of these messages. Delete them! On Wed, Sep 25, 2019 at 11:54 PM Jarrod Johnson <[email protected]<mailto:[email protected]>> wrote: I've been considering removing all of that from executing on rpm install (also enabling services to start on boot just by installing rpm) It was added for convenience of not asking to run a setup after install but it is inconsistent with general rpm behavior and limits ability to use flags to customize behavior. On the flip side, this would be a change that people would have to learn and would surprise new installs. I might make variant of the xCAT meta package with no auto setup so that people won't be surprised unless they opt into the other package. Looking for thoughts. For wider information, it doesn't yet have os deployment, but confluent has been developing and designing specifically with firewall and selinux in mind, as well as trying to mitigate the initial setup complexity that drove us to create xcatconfig in the first place. For example no more tls certs required for local access and os import will no longer loop mount isos (one of the biggest selinux problems) and avoid rewriting other service etc files in daemon context. More straightforward network usage and a documented set of firewalld commands. ________________________________ From: Vinícius Ferrão via xCAT-user <[email protected]<mailto:[email protected]>> Sent: Thursday, September 26, 2019 2:27:10 AM To: xCAT Users Mailing list Cc: Vinícius Ferrão Subject: [External] [xcat-user] xCAT forcibly disabling SELinux and firewalld Hello, When installing xCAT in EL7 with yum install xCAT it’s just put SELinux in permissive mode and disables firewalld. It does not even ask about it. It just does. [root@headnode ~]# getenforce Permissive [root@headnode ~]# systemctl status firewalld ● firewalld.service - firewalld - dynamic firewall daemon Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled) Active: inactive (dead) Docs: man:firewalld(1) Sep 26 02:55:55 headnode.cluster.iq.ufrj.br<http://headnode.cluster.iq.ufrj.br/> systemd[1]: Starting firewalld - dynamic firewall daemon... Sep 26 02:55:56 headnode.cluster.iq.ufrj.br<http://headnode.cluster.iq.ufrj.br/> systemd[1]: Started firewalld - dynamic firewall daemon. Sep 26 03:09:18 headnode.cluster.iq.ufrj.br<http://headnode.cluster.iq.ufrj.br/> systemd[1]: Stopping firewalld - dynamic firewall daemon... Sep 26 03:09:21 headnode.cluster.iq.ufrj.br<http://headnode.cluster.iq.ufrj.br/> systemd[1]: Stopped firewalld - dynamic firewall daemon. There’s a way to avoid this behaviour? Thanks, PS: I’m aware of the consequences of firewalld and SELinux in xCAT environments. _______________________________________________ xCAT-user mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/xcat-user _______________________________________________ xCAT-user mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/xcat-user _______________________________________________ xCAT-user mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/xcat-user
_______________________________________________ xCAT-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/xcat-user
