18:24:19 #startmeeting 18:24:19 Meeting started Mon Apr 5 18:24:19 2021 UTC. The chair is raub. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:24:19 Useful Commands: #action #agreed #help #info #idea #link #topic. 18:24:23 Jeoff seems to be having connection issues. 18:24:39 #chair bdmc noway2 18:24:39 Current chairs: bdmc noway2 raub 18:24:45 Me too 18:24:51 noway2 and I have been chatting 18:25:07 #topic 1. Check for Agenda Additions 18:25:18 #topic 2. Current Topics 18:25:40 Did you update noway2 on your ipv6 adventures? 18:26:37 We talked briefly, but I said that building machines and assigning tasks was much more urgent. As long as they can talk to each other, external networking can come along a bit later. 18:26:56 At present, we don't have ANY "real" new machines. 18:27:56 We've managed to get a couple of VMs up and running, but even that hasn't been a smooth process. 18:28:07 Can we create a "plan," deciding on how many machines to build and what they will do? 18:28:17 Well, are we going to move allt he services into a new machine or separate them? 18:28:37 As I said, I was successful using Mauricio's "script." 18:29:07 I thought that the plan was to separate functions, so that each new machine would have a specific purpose. 18:29:26 There is a page in the wiki outlining the last time this was done 18:29:35 I propose to resue it 18:29:45 OK. Address? 18:30:11 https://steering.trilug.org/wiki/index.php/PilotUpgradePlan 18:30:41 ( waiting for my browser ) 18:30:51 * raub plays elevator music 18:31:10 ( or --- darn -- Alex Trebek ) 18:32:29 That's ancient history. Did you really mean that? 18:32:46 Talking about Ubuntu 10. 18:32:59 I meant use the page, keep the layout, and adapt it for the current setup 18:33:30 i.e. it is a place to create the plan, and describe where we are and where we want to be 18:34:32 Perhaps. It really doesn't seem to talk much about services, just hardware configuration. 18:35:09 https://steering.trilug.org/wiki/index.php/PilotUpgradePlan#Configuration_and_Services 18:35:29 Looking over the services, we have mail (dovecot, postfix, postgrey), dns, web, ldap (login) and a few backend that are common like sql. 18:35:43 Note they also stated they needed to actually define the config 18:36:28 I would trust the lists that the three of us have compiled recently much more than that list. 18:36:47 then edit the page 18:37:30 I like the note just above that section. It is talking about exactly the problem that Matt and I were having. 18:38:25 Incidentally, as far as editing the page, I would much rather rename and archive this one, instead of losing the history. 18:38:52 I agree. the history is worth keeping. 18:39:12 https://steering.trilug.org/wiki/index.php?title=PilotUpgradePlan&action=history 18:39:54 That's too much like making sense. 18:40:07 Scary I know 18:40:37 Have to make an appropriate note for the History before any changes. 18:41:32 That is good documentation 18:42:19 OK, so who does what when? 18:43:13 First, we need to document the plan 18:43:26 I can put in that page what I had in mind and let you all edit 18:43:46 Sounds good to me. Deadline? 18:44:19 I will have that tomorrow. Tonight I have a meeting, so I may work after that on it 18:45:44 So Matt and I can edit after.....? 18:46:08 Supper time tomorrow, noon Wednesday, ??? 18:46:09 But, we also need a page on the network setup, or update the current one 18:46:23 I will send an email out when I put what I know 18:46:35 As I said, I will try to get it done tonight 18:46:48 Right. This page says "Pilot" upgrade, not TriLUG upgrade. 18:47:05 Do we have a separate page ( child page? ) regarding each VM, or? 18:47:20 Because we are upgrading pilot by breaking it apart 18:47:31 ( TriLUG Infrastructure ??? ) 18:47:55 Sure thing. They will not be "upgrade this VM" kinda of pages as they describe the config of these new vms 18:48:12 bdmc: ensure there is not such page already 18:48:29 Right, but do we have a paragraph for each VM, or a page? 18:48:50 page 18:49:01 Or we *should* end up with separate pages 18:49:27 OK. So chilren of the "new" Infrastructure page, or build everything under "Pilot Upgrade?" 18:49:53 As I said, they are not upgrade pages, so they go under infra 18:50:40 I would suggest a new tree, with this page pointing at the new one. ( Just a section at the bottom, saying that as of "April 2021," the following Infrastructure changes were made. ) 18:51:00 Also have the new tree show up in the Table of Contents. 18:51:21 ( got the quotes in the wrong place. ) 18:52:02 "This page was last modified on 8 February 2021, at 13:23" 18:52:14 The new tree could point at this old one, as "how it was before the changes of April 2021?? 18:52:38 This will get messy 18:52:59 Will get, or is already, messy 18:53:07 Right, but I meant that the paragraph on the Pilot Upgrade page would point at the new Infrastructure page, with a small explaination. 18:53:58 The Infrastructure page would be on the ToC for now and the future. 18:54:48 If there it not a page already doing something, create it. If there is, change it 18:55:22 In the main ToC is a page called "System Administration," which has a collection of various pages. My new page could go there. 18:55:28 The structure of the wiki is very flat as of now; I do not think there is much we can do 18:57:03 There is a page there from "DASH Systems." I don't know how old that is. 18:58:00 It probably can go, but is that relevant to the current project? 18:59:14 That's interesting. You edited it about a year ago, and the previous time was seven years earlier. 18:59:33 I do agree that stuff should be well documented, but it seems to me that we're running into a couple of technical issues that are at least partially resolved, that went beyond our expectations. Getting past those and getting a machine that can handle the mailing list up would seem to be a priority. 18:59:51 What I meant was that that "System Adminstration" page contains all sorts of things. 19:00:30 URL? 19:00:38 noway2: So you are talking about the "mailman" machine, correct? 19:01:11 raub: https://steering.trilug.org/wiki/index.php/Main_Page#System_Administration 19:01:35 OK, I thought you meant a separate "System Administration" page 19:02:23 bdmc: yes. I think we need to get something going on that, even if it is a temporary to get ourselves out of the proverbial fire. 19:03:58 There. No more "DASH Systems" 19:06:02 raub: When you did your measurements, did you include mailman? 19:06:46 Which measurements? Only one I did was mailbox. Are there other folders in the user account I should have, well, accounted for? 19:07:13 No, mailman is in /var 19:07:37 Then I did not account fo rit 19:08:38 Off the top of your heads, do either of you know what sort of free disk space we have in Moya? In other words, if we allocate 10G to each VM ( not counting the /home machine ), would that be reasonable? 19:09:06 How many VMs do we need? 19:09:19 We might want to double-check some things like, for instance, MailMan, Web and Mail. 19:09:34 I don't know. That is what I have been asking all day. 19:09:49 ( since we started talking today, anyway ) 19:10:04 Moya disk usage: /dev/dm-0 92G 11G 77G 13% / 19:10:19 Use is 13% 19:10:37 For root. Any other space in use? 19:11:13 That looks small for moya. Are you sure that is not pilot? 19:12:19 dev/mapper/moya_vg_L0-vm_data 745G 665G 44G 94% /var/lib/libvirt 19:12:37 all the others look like virtual tempfs 19:13:02 That is more like it 19:13:03 Yes, that is the other part. 19:13:18 Hmmm. Only 44 free. 19:13:42 I think that there is old space allocated to Dargo. 19:13:48 There is a lv there you can blow up 19:15:02 You aren't talking about "vm_data" are you? 19:15:31 Are the VM drives under the moya_vg_L0-vm_data? 19:15:32 You could expand that, though. 19:15:40 noway2: Yes 19:15:53 noway2: should be. 19:15:56 There is 1.5T free to add to that LVM. 19:16:06 bdmc: no. Testpilot or something like that 19:16:58 I don't see that one. Here is the list of "disks:" 19:17:03 crichton.qcow2.gz ipaserver1.qcow2.gz pilot.trilug.org.qcow2.backup.2020-01-12 rhel7.2.qcow2.gz sun zhaan_home.qcow2 zhaan_var.qcow2.gz 19:17:06 dargo.qcow2.gz pilot.trilug.org.qcow2 pilot2.qcow2 rygel.qcow2 tets zhaan_root.qcow2.gz 19:17:57 noway2@moya:~$ sudo vgdisplay moya_vg_L0 19:17:59 --- Volume group --- 19:18:00 VG Name moya_vg_L0 19:18:02 System ID 19:18:03 Format lvm2 19:18:05 Metadata Areas 1 19:18:06 My rygel and tets could go away. ( should go away ) Once we decide on what is needed both in number and size. 19:18:07 Metadata Sequence No 9 19:18:07 I will look for it and blow it up as needed 19:18:08 VG Access read/write 19:18:09 VG Status resizable 19:18:11 MAX LV 0 19:18:12 Cur LV 4 19:18:14 Open LV 3 19:18:16 Max PV 0 19:18:17 Cur PV 1 19:18:18 Act PV 1 19:18:20 VG Size 2.73 TiB 19:18:21 PE Size 4.00 MiB 19:18:23 Total PE 714530 19:18:24 Alloc PE / Size 296635 / 1.13 TiB 19:18:26 Free PE / Size 417895 / 1.59 TiB 19:18:27 VG UUID MRkP9F-LUE1-8ewd-cVKf-qien-eJrV-n3cWI7 19:18:43 noway2: next time, use vgs and lvs 19:19:26 raub: Yes, I see it now. Not a qcow disk, but a "real" one. 19:19:31 250G 19:19:40 Gotcha - I rolled with what DDG gave me. If I am reading that right, we have 1.59TiB free, though. 19:20:15 Right, as I said earlier. 19:20:52 So no space issues. Just need to make decisions. 19:21:10 I don't see a need to over-allocate, however. 19:21:46 Putting 250G on each VM, even if it will work with 5, doesn't make sense to me. 19:22:47 I propose just one VM to run the services. We can spool a dev one as needed 19:23:14 So, basically replace Pilot with a duplicate? 19:23:16 Second prod vm is for users 19:23:18 If I may offer an idea that just popped in my head: how about 2 VMs. One for administration stuff, like the mail, official web, etc and a second one that has the user sandboxes to play in? 19:23:29 I think we're saying the same thing at the same time. 19:23:30 Replace with two VMs: services and accounts/users 19:24:00 OK. First one shouldn't need more than 10-25G. Second one, 250G or so. 19:25:05 noway2: unless you know how to setup the sandboxes and can ensure they will not max out the resources 19:25:20 In that case, Moya, Admin ( Pilot? ) and Homes could each have a unique IPv4 address. 19:25:54 raub: Not sure what you are asking Matt. 19:26:14 Unless what? Or, where did that question come from? 19:26:50 unless noway2 can do that, I do not want to spend time with sandboxes right now 19:27:11 Didn't mean it in that sense - just keeping it seperate from the admin machine. 19:27:18 But wasn't that your suggestion? 19:27:22 Let's keep this simple. Just breaking pilot apart will be a ordeal 19:27:44 sandbox could mean each user has a separate sandbox 19:27:54 I, like you, was suggesting two machines. Not virtual sandboxes for the users. Poor choice of word. 19:28:03 noway2: K 19:28:18 Ahhh. Gotcha. I missed that/ 19:29:39 OK, so start with a plan for two machines, but build one, the "Admin" one. 19:30:06 Once that is up and running, it can take over for Pilot, and the second machine can be built. 19:30:11 Correct? 19:30:37 All through this, Pilot ( old ) retains the current IPv4 address. 19:30:44 Sounds like a plan to me. 19:30:58 Yes. I will document that in the upgrade plan page 19:33:27 Hmmmm. That's odd. I don't see my ( raub's ) VM-building script. 19:33:45 Now the other topic I want to go over is that we do not have a talk for this week 19:34:30 Found it. ( /etc/libvirt ) 19:34:37 Found it. ( /etc/libvirt/qemu ) 19:34:45 Oh? 19:34:55 No Jeoff? 19:35:44 I would offer to help, but I am being paid to be somewhere else that night. 19:36:54 I have not seen anythig[M F=[M#F= 19:37:13 = 19:37:20 =? 19:37:23 B-) 19:38:52 No worries 19:40:08 In any case, I have not seen anything from jeoff. So we need something 19:40:41 Guided chat session? 19:41:41 I don't know. THis is not a week I have a lot of free time to come up with something 19:43:15 Understood. That was why I suggested that. You could start with a topic, or solicit one, and get everybody to participate. ( Or "Read the News," Linux news, of course. ) I didn't see anybody respond to my "30 years old" message in the mailing list. 19:44:20 K. Let's see if I make time for that. Updating the update page comes first. And there are other itmes before that 19:45:40 I was hoping that that wouldn't take much preparation time. Anyway, let us know when there is something to contribute. 19:45:52 Documentation wise. 19:46:38 K 19:46:48 In any case, that is all I have for now 19:47:09 Gee. We haven't passed 3.5 hours, yet. 19:47:29 Bye? 19:47:34 Yep 19:47:36 Seeya 19:47:38 Ha ha. I think we're good fro today 19:47:38 #endmeeting