17:00:27 <pboy> #startmeeting fedora-server
17:00:27 <zodbot> Meeting started Wed Jul 19 17:00:27 2023 UTC.
17:00:27 <zodbot> This meeting is logged and archived in a public location.
17:00:27 <zodbot> The chair is pboy. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
17:00:27 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
17:00:27 <zodbot> The meeting name has been set to 'fedora-server'
17:00:38 <eseyman> meeting time!
17:00:40 <pboy> #topic Welcome / roll call
17:00:52 <pboy> Welcome to our Server WG IRC meeting today!
17:00:54 <eseyman> .hello2 eseyman
17:00:55 <zodbot> eseyman: eseyman 'Emmanuel Seyman' <emmanuel@seyman.fr>
17:01:05 <jwhimpel> .hello
17:01:05 <zodbot> jwhimpel: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
17:01:13 <pboy> Hi eseyman, right on time today. :-)
17:01:32 <jwhimpel> .hello2
17:01:34 <zodbot> jwhimpel: jwhimpel 'John Himpel' <john@jlhimpel.net>
17:01:45 * nirik has another meeting at the same time as usual. ;( but here in the background...
17:02:28 <pboy> hi nirik, we may need you for top 3 (your technical opinium)
17:03:12 <pboy> OK, let's stat with the agenda
17:03:21 <pboy> #topic Agenda
17:03:30 <pboy> #info  Follow up actions
17:03:33 <nirik> I can try... ;)
17:03:39 <pboy> info  Fedora 39 change Proposal:  Enable Firmware Update Notification
17:03:48 <pboy> #info  LLMNR should be disabled in resolved in f39
17:03:58 <pboy> #info  Work Project: Using Ansible to install and configure Wildfly
17:04:10 <pboy> #info  F39/40 Work Project: Fedora Server in a virtualized runtime environment
17:04:19 <pboy> #info  Open floor
17:04:29 <pboy> Any topic to add?
17:04:37 <pboy> I think we have a lot
17:04:42 <eseyman> agreed
17:04:58 <pboy> #topic 1. Follow up actions
17:05:12 <pboy> #action pboy will write a info about changing the timeout value and nirik will review – still work in progress
17:05:21 <pboy> #info ACTION: eseyman will review the NFS documentation - done
17:05:41 <pboy> The NFS doc needs still some work. Eseyman will complete the text? hopefuly
17:06:00 <pboy> Nothing to announce
17:06:12 <pboy> Any addition?
17:06:49 <pboy> Obviously not
17:06:57 <pboy> #topic 2.  Fedora 39 change Proposal:  Enable Firmware Update Notification
17:07:02 <eseyman> I wanted to reply in private but sent the reply to the list
17:07:07 <eseyman> Sorry about that
17:07:36 <pboy> OK
17:07:51 <pboy> #link https://pagure.io/fedora-server/issue/115
17:08:01 <pboy> If possible, 10 mins max.
17:08:19 <pboy> We had an ad hoc discussion and we have a decision
17:08:46 <pboy> maybe  we will share additional ideas?
17:08:57 <pboy> I had the idea to add mail notification. But server as we distribute, there is no mail server installed.
17:09:21 <pboy> So it's nothing for this year. :-)
17:09:34 <eseyman> the issue is who to send mail to...
17:09:51 <pboy> Yes, indeed. that's tghe 2nd peroblem
17:10:11 <pboy> logwatch sends to root@localhost
17:10:26 <pboy> Hopefully, the disk is large enough
17:11:08 <eseyman> in /etc/aliases, there's a commented-out alias from root to marc
17:11:53 <pboy> Yeah, so that's an easy way to determine an addressee
17:12:14 <pboy> But you must edit the file after installation. ....
17:13:07 <pboy> There are some very light weigt mail sending progs. Maybe, we can install one of them with the reworked installation media.
17:13:29 <pboy> And then it may be useful.
17:13:52 <eseyman> and even sending to /var/spool/mail/$USER does not mean the mail will get read
17:14:19 <pboy> No, you need to send it to someones daily mail account.
17:14:37 <eseyman> honestly, I would just ask during installation "do you want email notifications? if so, to which address?"
17:14:39 <pboy> But then it might be helpful.
17:15:07 <pboy> eseyman I suppose RPM doesn't support that.
17:15:25 <pboy> So we would have to do it with Anaconda
17:15:41 <pboy> That's not trivial
17:16:19 <pboy> But a message of the day when you occasionally log in is better than nothing
17:16:21 <eseyman> yes
17:16:31 <pboy> OK, let's switch
17:16:43 <jwhimpel> pboy: Hopefully the rewrite of the installer that is currently progressing will make future changes easier.
17:17:04 <pboy> Yes, I hope so!
17:17:08 <pboy> #topic 3. LLMNR should be disabled in resolved in f39
17:17:18 <pboy> #link https://pagure.io/fedora-server/issue/114
17:17:28 <pboy> Change proposal
17:17:39 <pboy> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DCX54HQNCPT56XDGVXXTHMDPGHJWKT7A/#DCX54HQNCPT56XDGVXXTHMDPGHJWKT7A
17:17:48 <pboy> Diskussion:
17:18:01 <pboy> #link https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/DCX54HQNCPT56XDGVXXTHMDPGHJWKT7A/#DCX54HQNCPT56XDGVXXTHMDPGHJWKT7A
17:18:32 <pboy> We are explicitely asked about it via ticket system. So we should deal with it.
17:18:46 <pboy> I think, it's useful. But I'm not familiar with the technical details.
17:19:06 <pboy> nirik here is your part
17:19:10 <pboy> :-)
17:19:55 <eseyman> no opinion
17:21:02 <pboy> Yeah, it sounds like a good idea. But that's just on the surface.
17:22:38 <eseyman> would be nice to get the systemd maintainers' opinion on the subject
17:23:25 <pboy> We use split DNS a lot. But that has nothing to with multicast as to my little knowledge
17:24:26 <pboy> And DNSSEC would be really fine.
17:24:54 <pboy> Well, nirik seems to be busy.
17:25:27 <eseyman> DNSSEC would be much appreciated...
17:26:03 <pboy> proposal, because we have no dedicated opinion and are not familiar enough, I'll work out an answer together with nirik, as soon as he can manage
17:26:41 <pboy> any objection?
17:27:25 <pboy> None, so
17:27:49 <eseyman> no
17:28:15 <pboy> #agreed. pboy and nirik will resolve the issue on behalf of Server WG.
17:28:28 <pboy> #agreed pboy and nirik will resolve the issue on behalf of Server WG.
17:28:55 <pboy> #topic 4. Work Project: Using Ansible to install and configure Wildfly
17:29:07 <pboy> #link https://pagure.io/fedora-server/issue/60
17:29:24 <pboy> It's the main topic today.
17:29:37 <pboy> Objective here. Deciding about the next steps
17:29:59 <pboy> Besides the certificate issue, we have to plan
17:30:22 <pboy> * What proxy to use (Apache httpd, Nginx, HAproxy, all of them
17:30:25 <eseyman> we still have certificate issues ???
17:30:32 <pboy> * Where to store the software: /opt/wildfly or anywhere else?
17:30:48 <pboy> * How organize storage
17:30:57 <pboy> * How to make the Ansible playbook
17:31:10 <pboy> I hope that all for now.
17:31:29 <jwhimpel> The current role that I am working on configures a standalone version of wildfly.  Should we have another role(s) to configure a cluster of servers?
17:31:32 <pboy> John, can you give the latest status of the certificate issue?
17:31:58 <pboy> I think, we should start with a standalone.
17:32:19 <eseyman> standalone alone is fine
17:32:46 <jwhimpel> I've had another round of health issues, so I have not made any progress.  I did find a link that seemed to address the certificate issue.  I promise to have tried that approach by our next meeting in August
17:33:23 <eseyman> as for the proxy in front, I'm mostly in favour of nginx
17:33:38 <pboy> Yeaj John, too.  :-)
17:33:43 <eseyman> but this should be controlled via a variable in the playbook
17:34:15 <jwhimpel> There's some good documentation on how to configure that on the web.
17:34:25 <pboy> Well, Fedora policy is, to prefer Apache
17:34:39 <pboy> But proxy is a bit weak with httpd
17:34:53 <jwhimpel> From an ansible standpoint, I think configuring a proxy should be a separate role.  One role for each type of proxy frontend.
17:35:03 <pboy> If I remember correctly, nginx supports the proxy proticoll
17:35:09 <pboy> as dies haproxy.
17:35:20 <pboy> Does someone know more details?
17:35:36 <pboy> Because the proxy protocol is quite important
17:35:50 <pboy> for traffic analyses, e.g.
17:36:09 <jwhimpel> Either would work.  Question: If we have a standalone instance of wildfly, why do we need a proxy?  I ask out of ignorance rather than out of objection.
17:37:06 <eseyman> either to serve static files better than wildfly or protect wildfly from attacks
17:37:14 <pboy> Without a proxy, wildfly uses port 80 exclusivly for the complete server. No other web service would be poissible
17:38:29 <pboy> And I'm not sure, tomcat is quite slow in distributing static pages and is of limited funtionality
17:38:34 <jwhimpel> wildfly uses port 8080 not 80
17:38:47 <pboy> Or is nowadays apache integrated in wildfly?
17:39:21 <pboy> Yes, indeed. But by default everybody uses port 80.
17:39:27 <jwhimpel> Wildfly has an integrated servlet processor and is also capable of serving static pages.
17:39:48 <pboy> OK, that's like tomcat
17:40:28 <pboy> Nevertheless, you want your service be accessible via port 80 / 443. Everybody uses it.
17:40:41 <pboy> And most not even kknow about 8080
17:40:45 <jwhimpel> Disclaimer: I haven't actually used the integrated servlet processor, but I recall seeing that in the documentation.
17:41:25 <pboy> jwhimpel we use it a lot in our project. It is our main and default servlet processor.
17:41:58 <jwhimpel> I'm used to having port 80 pages with links pointing to 8080.  But I understand your point and would not object to having a proxy in front.
17:42:00 <pboy> and we have always a proxy in front because we server several domains  all on 80
17:42:49 <pboy> jwhimpel that's the 'poor mans proxy'. :-)
17:43:19 <pboy> OK, we use a proxy and start with nginx.
17:43:56 <pboy> For the books: nginx can proxy protocol, and Apache can't. That makes nginx the better solution.
17:44:36 <pboy> And haproxy might be an alternative for high traffic sites. We do that later (if at all. :-) )
17:45:06 <pboy> I guess, no objection
17:45:38 <jwhimpel> Before our next meeting, I will also upgrade the role to install the latest version of wildfly (the current role is 2 versions behind).
17:45:57 <pboy> #agreed We'll use nginx as proxy solution, because it is able to handle the proxy protocol.
17:46:04 <jwhimpel> I do install the software into /opt/wildfly  is that okay with everyone?
17:46:23 <pboy> That's the next question.
17:46:42 <pboy> According to FHS, I think, it is the best solution .
17:47:09 <eseyman> probably
17:47:15 <pboy> But tomcat installs into usr/share and /var/lib for datá and /etc for configuration
17:47:35 <pboy> It uses sym link to spread the locations
17:47:44 <eseyman> again, please make this a variable in the role so that it can be easily changed if need be
17:47:48 <pboy> Do we have a Fedora policy about that?
17:48:45 <pboy> I see, nobody knows.?
17:48:59 <eseyman> not me
17:49:07 <jwhimpel> Me neither.
17:49:09 <pboy> Then I would peropose, we ask Jave SIG. I could do that.
17:49:58 <pboy> #action pboy asks Java SIG about best practise for a installation location.
17:50:37 <pboy> Nest issue: storage organisation.
17:51:10 <pboy> Our official solution is, to use LVM LVs to store data, separate from the system files.
17:51:41 <pboy> I think, we should do so in our Ansible playbook.
17:52:16 <pboy> We could either make a LV for /opt, or a thin provisioned for /opt/Ansible
17:52:44 <pboy> I mean /opt/wildfly
17:53:09 <jwhimpel> If we go that route, I would suggest /opt/Wildfly as a LV
17:53:39 <eseyman> oh yes
17:53:52 <pboy> Yes, would be the best. we would have the option to make snapshot just for that.
17:54:15 <pboy> OK, we ...
17:54:50 <jwhimpel> Question: Do we want to support multiple simultaneous versions of Wildfly on a single host?
17:54:55 <pboy> #agreed we will create a separate log. Volume for /opt/wildfly according the Fedora Server Edition storage concept.
17:55:17 <pboy> jwhimpel I think that would be great!
17:55:30 <pboy> Tomcat is able to do that.
17:56:14 <pboy> With Tomcat you use one binary and several data locations.
17:56:46 <pboy> If I remember correctly, the wildfly RPM could that, too
17:57:00 <pboy> years back, when we had one
17:57:40 <jwhimpel> Since Wildfly is updated every six months, it would not be unusual to need Wildfy 45 and 46 needed simultaneously.  That is what I was asking about.
17:57:59 <jwhimpel> Sorry, I need to run to Doctor appointment now.
17:58:23 <pboy> I'm not sure. Often there is a lot of change and you have a lot to adjust.
17:58:40 <pboy> OK. I think we have done a lot today!
17:58:45 <pboy> And our time is up.
17:59:15 <pboy> Let's discuss the multiversion / multi instances question next time.
17:59:25 <eseyman> yes
17:59:36 <pboy> Well, open floor
17:59:46 <pboy> #topic  5. Open Floor
18:00:21 <pboy> eseyman By he way, I translated my German pieces int he nfs doc.
18:00:35 <eseyman> pboy: will review again
18:00:44 <pboy> thanks.
18:00:53 <eseyman> do you want a review of the mail documentation ?
18:01:41 <pboy> yes, but is is not complete yet. But the postfix part and the dovecot part are complete - at least I hope so
18:01:54 <eseyman> will review
18:02:06 <pboy> You did some work with mail recently?
18:02:13 <pboy> Thanks-
18:02:23 <pboy> Anything else?
18:02:27 <eseyman> pboy: it's still ongoing
18:02:50 <pboy> OK, maybe we get some more insight from it.
18:03:09 <pboy> It's quite complidated with SPF, dmarc and dkim
18:03:21 <eseyman> but yeah, I have two smtp gateway serving 200k emails daily
18:03:44 <pboy> Oh that't a lot
18:04:06 <pboy> Ours at University is similiar
18:04:30 <eseyman> I call this moderately high volume
18:04:44 <pboy> Yeah
18:05:03 <pboy> OK, I think we close now.
18:05:17 <pboy> Thanks everyone for comming
18:05:25 <pboy> bye bye
18:05:35 <pboy> #endmeeting