- WLUG - wlug.mailman3.com

Re: Reminder: WLUG Meeting tonight: Topic ProxMox / Turning Pi 2

by Kevin Harrington

Bancroft School where I work would be very interested in the desktops and laptops. I am trying to build a Linux CAD lab, and all I have are 12 year old macs with 8gb ram. Do they have 16+gb ram? On Sat, Feb 10, 2024, 9:23 PM Pete Wason via WLUG <wlug(a)lists.wlug.org> wrote: > Heya - fun meeting, cool stuff! I meant to mention, I have a ton > (literally) of decommissioned equipment at work we're looking to > give/sell/donate away. Mostly Dell, but some other brands mixed in. I may > have posted a partial list at some point on the list. A few older servers > (R805, R300, two 32-bay Celeros NAS units, Synology RS2416+ with SAS > expansion chassis), Optiplex and Precision desktops, a few Precision > laptops (that cost us between$4-7K when new), a 16-port KVM, about 30 > monitors, keyboards, mice, etc. etc. etc. > > If you know anyone who needs any more tech to play with, I have it! I also > have a bunch of stuff at home that's available. > > Pete Wason > Clark Labs > 921 Main Street > Worcester, MA > pwason(a)clarku.edu > 508 849 2323 (Desk) > 774 922 7202 (Cell) > On 2/8/2024 2:11 PM, Tim Keller via WLUG wrote: > > Hey Everybody! > > We've got a meeting tonight! > Time: 7pm > Date: February 8th, 2024 > Location: Technocopia, 44 Portland St. Worcester MA > Virtual Location: https://meet.jit.si/WlugMA > > For a topics, We've got two. > > Topic #1: Turing Pi 2 hardware > Wlug member Zori Babroudi recently bought a Turning Pi 2 and a bunch of Pi > and Rocks compute modules. > Currently, it's a work in progress, but eventually once things are totally > working on it, I'd like to show it off in its full glory. But in the > meantime, we can marvel at the hardware. Ultimately, the plan is to run k8s > on it and do some LLM based AI stuff as well. > > Topic #2: ProxMox > With BroadCom's purchase and destruction of VMware, many of us are > scrambling to look for > alternatives to VMware Esxi. One great contender is ProxMox. It's a debian > based distro that's focused on providing a great interface to manage vms > running on kvm. It also has great support for video card pass through > (something I know Brandon is *very* interested in). I've got a 3 node > proxmox cluster that I will show off. John Stoffel has also been > experimenting with it as well so both of us can talk about the > good/bad/ugly of it. > > As usual, the conversation will be lively and focused around linux, FOSS, > fair use and who knows what! > > Afterwards we'll head off for some dinner and keep the conversation going! > I hope to see you there! > Later, > Tim. > > > -- > I am leery of the allegiances of any politician who refers to their > constituents as "consumers". > > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/ZL6T6… > > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive: > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/FVWLG… >

Feb. 11, 2024

Re: Reminder: WLUG Meeting tonight: Topic ProxMox / Turning Pi 2

by Pete Wason

Heya - fun meeting, cool stuff! I meant to mention, I have a ton (literally) of decommissioned equipment at work we're looking to give/sell/donate away. Mostly Dell, but some other brands mixed in. I may have posted a partial list at some point on the list. A few older servers (R805, R300, two 32-bay Celeros NAS units, Synology RS2416+ with SAS expansion chassis), Optiplex and Precision desktops, a few Precision laptops (that cost us between$4-7K when new), a 16-port KVM, about 30 monitors, keyboards, mice, etc. etc. etc. If you know anyone who needs any more tech to play with, I have it! I also have a bunch of stuff at home that's available. Pete Wason Clark Labs 921 Main Street Worcester, MA pwason(a)clarku.edu 508 849 2323 (Desk) 774 922 7202 (Cell) On 2/8/2024 2:11 PM, Tim Keller via WLUG wrote: > Hey Everybody! > > We've got a meeting tonight! > Time: 7pm > Date: February 8th, 2024 > Location: Technocopia, 44 Portland St. Worcester MA > Virtual Location: https://meet.jit.si/WlugMA > > For a topics, We've got two. > > Topic #1: Turing Pi 2 hardware > Wlug member Zori Babroudi recently bought a Turning Pi 2 and a bunch of Pi and Rocks compute modules. > Currently, it's a work in progress, but eventually once things are totally working on it, I'd like to show it off in its full > glory. But in the meantime, we can marvel at the hardware. Ultimately, the plan is to run k8s on it and do some LLM based AI > stuff as well. > > Topic #2: ProxMox > With BroadCom's purchase and destruction of VMware, many of us are scrambling to look for > alternatives to VMware Esxi. One great contender is ProxMox. It's a debian based distro that's focused on providing a great > interface to manage vms running on kvm. It also has great support for video card pass through (something I know Brandon is > /very/ interested in). I've got a 3 node proxmox cluster that I will show off. John Stoffel has also been experimenting with > it as well so both of us can talk about the good/bad/ugly of it. > > As usual, the conversation will be lively and focused around linux, FOSS, fair use and who knows what! > > Afterwards we'll head off for some dinner and keep the conversation going! > I hope to see you there! > Later, > Tim. > > > -- > I am leery of the allegiances of any politician who refers to their constituents as "consumers". > > _______________________________________________ > WLUG mailing list --wlug(a)lists.wlug.org > To unsubscribe send an email towlug-leave(a)lists.wlug.org > Create Account:https://wlug.mailman3.com/accounts/signup/ > Change Settings:https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive:https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org…

Feb. 11, 2024

Re: Hey Everybody! WLUG Meeting this week!

by John Stoffel

>>>>> "Keith" == Keith Wright via WLUG <wlug(a)lists.wlug.org> writes: > Tim Keller via WLUG <wlug(a)lists.wlug.org> writes: >> We've got a WLUG meeting on the 8th! I know weirdly early in the month >> because the 1st landed on a Thursday! >> >> As for the meeting details: >> Time: 7pm >> Date: 2/8/2024 >> Location: Techncopia > I notice you did not mention > Virtual Location: https://meet.jit.si/WlugMA > I missed the last meeting, but I think I could log in this > evening. Did you decide to scrap it? Nope, we'll be there tonight and hopefully online by 7pm.

Feb. 8, 2024

Reminder: WLUG Meeting tonight: Topic ProxMox / Turning Pi 2

by Tim Keller

Hey Everybody! We've got a meeting tonight! Time: 7pm Date: February 8th, 2024 Location: Technocopia, 44 Portland St. Worcester MA Virtual Location: https://meet.jit.si/WlugMA For a topics, We've got two. Topic #1: Turing Pi 2 hardware Wlug member Zori Babroudi recently bought a Turning Pi 2 and a bunch of Pi and Rocks compute modules. Currently, it's a work in progress, but eventually once things are totally working on it, I'd like to show it off in its full glory. But in the meantime, we can marvel at the hardware. Ultimately, the plan is to run k8s on it and do some LLM based AI stuff as well. Topic #2: ProxMox With BroadCom's purchase and destruction of VMware, many of us are scrambling to look for alternatives to VMware Esxi. One great contender is ProxMox. It's a debian based distro that's focused on providing a great interface to manage vms running on kvm. It also has great support for video card pass through (something I know Brandon is *very* interested in). I've got a 3 node proxmox cluster that I will show off. John Stoffel has also been experimenting with it as well so both of us can talk about the good/bad/ugly of it. As usual, the conversation will be lively and focused around linux, FOSS, fair use and who knows what! Afterwards we'll head off for some dinner and keep the conversation going! I hope to see you there! Later, Tim. -- I am leery of the allegiances of any politician who refers to their constituents as "consumers".

Feb. 8, 2024

Re: Firewalld/iptables/nftables question

by William Grenache

Understood - Thank you. Bill On Thursday, February 8, 2024 at 11:01:43 AM EST, Patrick McEvilly via WLUG <wlug(a)lists.wlug.org> wrote: The systems we are building are just forwarders out to a $$$Splunk cloud syslog thing. So disk space is not a huge issue for us. From: William Grenache <grenache7994(a)verizon.net> Date: Thursday, February 8, 2024 at 9:57 AM To: John Stoffel <john(a)stoffel.org>, Patrick McEvilly via WLUG <wlug(a)lists.wlug.org> Cc: Patrick McEvilly <pmcevilly(a)gmail.com> Subject: Re: [WLUG] Re: Firewalld/iptables/nftables question Question on Syslog location - Will this be deployed on a server / VM with internal or external storage? Wouldnt you have to partition the drive/s if internal storage is used? I may be over thinking this. On Wednesday, February 7, 2024 at 06:05:48 PM EST, Patrick McEvilly via WLUG <wlug(a)lists.wlug.org> wrote: Our logging folks that operate the $$$$$$syslog server said they were unable to parse our firewall logs once we sent them using tcp. ¯\_(ツ)_/¯ As I indicated in my initial email I'm out over my skis a bit. I'll take a look at rsyslog and see if the docs are dumb enough for my level of skills. Ack on the Host OS, Bus Drivers, etc. We will see how it goes once we load it up. P. On 2/7/24, 5:44 PM, "John Stoffel" <john(a)stoffel.org <mailto:john@stoffel.org>> wrote: >>>>> "Patrick" == Patrick McEvilly <pmcevilly(a)gmail.com <mailto:pmcevilly@gmail.com>> writes: > Based on a suggestion here we setup Nginx and it looks like it is > doing what we need but open to other solutions too. We will check > out rsyslog too. rsyslog should be your goto here, especially since with all those devices, you might want to filter them into different lots based on the source IP, etc. > Logs are from about 2500 networking devices including firewall, > routers, AAA servers, wireless controllers on a sizeable campus > network. Ok, so are these devices sending only via UDP or can you turn them on to use TCP? TCP will help keep down message loss, but for your busier devices, you might run into problems. > We are testing with one firewall and its generating about 7,000 log > messages a second. This is probably on the high side; some devices > will be almost zero. I would try using rsyslog in this case. It's certainly easier to setup than syslog-ng, which was a damn disaster in my book. Super flexible, lots nad lots of options, but just a total pain in the ass to get working right. > The hosts are VMs (I will have two) that we are just getting the > configuration going on, we have not loaded it up with all the logs > yet so hard to tell CPU usage. Currently it is almost zero. We can > throw more cpu/memory at it if it is a problem. Make sure you have good networking into these syslog destination VMs. > Having the source send two copies of the same logs is possible > though now our gear is going to processing more log data than actual > data __ Sure, makes sense. Nice to just point everything at 'log.internal.local' and let that system duplicate the data to multiple destinations or backends. > The real issue if we can't trust the folks we are sending logs to to > not move or change to another site/location/cloud whoever is on sale > this week. Keeping some central log boxes makes it so we only have > to change the target on these two syslog hosts and not on all 2500 > devices. I understand completely! I'm happy to answer questions and give you example configs. The docs for rsyslog are ok, but sometimes the examples are a little lacking for real world examples. Obviously written by people who know the stuff inside out, but can't write for smart but ignorant use cases. :-) You could also have rsyslog save a copy locally, and then send in to another host. If you're looking for fully redundant setup, then you might need a load balancer of some sort. It's hard to get complete logging without doing funky things because having a fully redundant setup is nice simple to do right. But also, check your other system configs at the base OS level. And check your VM's bus drivers. Some network cards will have better performance than others. Depending on how you have your virtualization setup, you might need to tweak your VM's hardware setup to get better network performance. John _______________________________________________ WLUG mailing list -- wlug(a)lists.wlug.org To unsubscribe send an email to wlug-leave(a)lists.wlug.org Create Account: https://wlug.mailman3.com/accounts/signup/ Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/ABJGX… _______________________________________________ WLUG mailing list -- wlug(a)lists.wlug.org To unsubscribe send an email to wlug-leave(a)lists.wlug.org Create Account: https://wlug.mailman3.com/accounts/signup/ Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/FPPRL…

Feb. 8, 2024

Re: Firewalld/iptables/nftables question

by Patrick McEvilly

The systems we are building are just forwarders out to a $$$Splunk cloud syslog thing. So disk space is not a huge issue for us. From: William Grenache <grenache7994(a)verizon.net> Date: Thursday, February 8, 2024 at 9:57 AM To: John Stoffel <john(a)stoffel.org>, Patrick McEvilly via WLUG <wlug(a)lists.wlug.org> Cc: Patrick McEvilly <pmcevilly(a)gmail.com> Subject: Re: [WLUG] Re: Firewalld/iptables/nftables question Question on Syslog location - Will this be deployed on a server / VM with internal or external storage? Wouldnt you have to partition the drive/s if internal storage is used? I may be over thinking this. On Wednesday, February 7, 2024 at 06:05:48 PM EST, Patrick McEvilly via WLUG <wlug(a)lists.wlug.org> wrote: Our logging folks that operate the $$$$$$syslog server said they were unable to parse our firewall logs once we sent them using tcp. ¯\_(ツ)_/¯ As I indicated in my initial email I'm out over my skis a bit. I'll take a look at rsyslog and see if the docs are dumb enough for my level of skills. Ack on the Host OS, Bus Drivers, etc. We will see how it goes once we load it up. P. On 2/7/24, 5:44 PM, "John Stoffel" <john(a)stoffel.org<mailto:john@stoffel.org> <mailto:john@stoffel.org>> wrote: >>>>> "Patrick" == Patrick McEvilly <pmcevilly(a)gmail.com<mailto:pmcevilly@gmail.com> <mailto:pmcevilly@gmail.com>> writes: > Based on a suggestion here we setup Nginx and it looks like it is > doing what we need but open to other solutions too. We will check > out rsyslog too. rsyslog should be your goto here, especially since with all those devices, you might want to filter them into different lots based on the source IP, etc. > Logs are from about 2500 networking devices including firewall, > routers, AAA servers, wireless controllers on a sizeable campus > network. Ok, so are these devices sending only via UDP or can you turn them on to use TCP? TCP will help keep down message loss, but for your busier devices, you might run into problems. > We are testing with one firewall and its generating about 7,000 log > messages a second. This is probably on the high side; some devices > will be almost zero. I would try using rsyslog in this case. It's certainly easier to setup than syslog-ng, which was a damn disaster in my book. Super flexible, lots nad lots of options, but just a total pain in the ass to get working right. > The hosts are VMs (I will have two) that we are just getting the > configuration going on, we have not loaded it up with all the logs > yet so hard to tell CPU usage. Currently it is almost zero. We can > throw more cpu/memory at it if it is a problem. Make sure you have good networking into these syslog destination VMs. > Having the source send two copies of the same logs is possible > though now our gear is going to processing more log data than actual > data __ Sure, makes sense. Nice to just point everything at 'log.internal.local' and let that system duplicate the data to multiple destinations or backends. > The real issue if we can't trust the folks we are sending logs to to > not move or change to another site/location/cloud whoever is on sale > this week. Keeping some central log boxes makes it so we only have > to change the target on these two syslog hosts and not on all 2500 > devices. I understand completely! I'm happy to answer questions and give you example configs. The docs for rsyslog are ok, but sometimes the examples are a little lacking for real world examples. Obviously written by people who know the stuff inside out, but can't write for smart but ignorant use cases. :-) You could also have rsyslog save a copy locally, and then send in to another host. If you're looking for fully redundant setup, then you might need a load balancer of some sort. It's hard to get complete logging without doing funky things because having a fully redundant setup is nice simple to do right. But also, check your other system configs at the base OS level. And check your VM's bus drivers. Some network cards will have better performance than others. Depending on how you have your virtualization setup, you might need to tweak your VM's hardware setup to get better network performance. John _______________________________________________ WLUG mailing list -- wlug(a)lists.wlug.org<mailto:wlug@lists.wlug.org> To unsubscribe send an email to wlug-leave(a)lists.wlug.org<mailto:wlug-leave@lists.wlug.org> Create Account: https://wlug.mailman3.com/accounts/signup/ Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/ABJGX…

Feb. 8, 2024

Re: Firewalld/iptables/nftables question

by William Grenache

Question on Syslog location - Will this be deployed on a server / VM with internal or external storage? Wouldnt you have to partition the drive/s if internal storage is used? I may be over thinking this. On Wednesday, February 7, 2024 at 06:05:48 PM EST, Patrick McEvilly via WLUG <wlug(a)lists.wlug.org> wrote: Our logging folks that operate the $$$$$$syslog server said they were unable to parse our firewall logs once we sent them using tcp. ¯\_(ツ)_/¯ As I indicated in my initial email I'm out over my skis a bit. I'll take a look at rsyslog and see if the docs are dumb enough for my level of skills. Ack on the Host OS, Bus Drivers, etc. We will see how it goes once we load it up. P. On 2/7/24, 5:44 PM, "John Stoffel" <john(a)stoffel.org <mailto:john@stoffel.org>> wrote: >>>>> "Patrick" == Patrick McEvilly <pmcevilly(a)gmail.com <mailto:pmcevilly@gmail.com>> writes: > Based on a suggestion here we setup Nginx and it looks like it is > doing what we need but open to other solutions too. We will check > out rsyslog too. rsyslog should be your goto here, especially since with all those devices, you might want to filter them into different lots based on the source IP, etc. > Logs are from about 2500 networking devices including firewall, > routers, AAA servers, wireless controllers on a sizeable campus > network. Ok, so are these devices sending only via UDP or can you turn them on to use TCP? TCP will help keep down message loss, but for your busier devices, you might run into problems. > We are testing with one firewall and its generating about 7,000 log > messages a second. This is probably on the high side; some devices > will be almost zero. I would try using rsyslog in this case. It's certainly easier to setup than syslog-ng, which was a damn disaster in my book. Super flexible, lots nad lots of options, but just a total pain in the ass to get working right. > The hosts are VMs (I will have two) that we are just getting the > configuration going on, we have not loaded it up with all the logs > yet so hard to tell CPU usage. Currently it is almost zero. We can > throw more cpu/memory at it if it is a problem. Make sure you have good networking into these syslog destination VMs. > Having the source send two copies of the same logs is possible > though now our gear is going to processing more log data than actual > data __ Sure, makes sense. Nice to just point everything at 'log.internal.local' and let that system duplicate the data to multiple destinations or backends. > The real issue if we can't trust the folks we are sending logs to to > not move or change to another site/location/cloud whoever is on sale > this week. Keeping some central log boxes makes it so we only have > to change the target on these two syslog hosts and not on all 2500 > devices. I understand completely! I'm happy to answer questions and give you example configs. The docs for rsyslog are ok, but sometimes the examples are a little lacking for real world examples. Obviously written by people who know the stuff inside out, but can't write for smart but ignorant use cases. :-) You could also have rsyslog save a copy locally, and then send in to another host. If you're looking for fully redundant setup, then you might need a load balancer of some sort. It's hard to get complete logging without doing funky things because having a fully redundant setup is nice simple to do right. But also, check your other system configs at the base OS level. And check your VM's bus drivers. Some network cards will have better performance than others. Depending on how you have your virtualization setup, you might need to tweak your VM's hardware setup to get better network performance. John _______________________________________________ WLUG mailing list -- wlug(a)lists.wlug.org To unsubscribe send an email to wlug-leave(a)lists.wlug.org Create Account: https://wlug.mailman3.com/accounts/signup/ Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/ABJGX…

Feb. 8, 2024

Re: Hey Everybody! WLUG Meeting this week!

by Keith Wright

Tim Keller via WLUG <wlug(a)lists.wlug.org> writes: > We've got a WLUG meeting on the 8th! I know weirdly early in the month > because the 1st landed on a Thursday! > > As for the meeting details: > Time: 7pm > Date: 2/8/2024 > Location: Techncopia I notice you did not mention Virtual Location: https://meet.jit.si/WlugMA I missed the last meeting, but I think I could log in this evening. Did you decide to scrap it? -- Keith

Feb. 8, 2024

Re: Firewalld/iptables/nftables question

by soup

Syslog over TCP is, relatively, new so if they’re running boat anchor tech or haven’t run into it previous it’ll be an issue def. Nginx’ll do you for a good while, not the ideal thing, but what is. If you need something easy deploy multiplat single-bin down the road caddy with the L4 module built in should work a treat but I haven’t tested it in this kind of bodge. Great project though. Take care, soup On Wednesday, February 7, 2024, Patrick McEvilly via WLUG < wlug(a)lists.wlug.org> wrote: > Our logging folks that operate the $$$$$$syslog server said they were > unable to parse our firewall logs once we sent them using tcp. ¯\_(ツ)_/¯ > > As I indicated in my initial email I'm out over my skis a bit. I'll take > a look at rsyslog and see if the docs are dumb enough for my level of > skills. > > Ack on the Host OS, Bus Drivers, etc. We will see how it goes once we > load it up. > > P. > > > > On 2/7/24, 5:44 PM, "John Stoffel" <john(a)stoffel.org <mailto: > john(a)stoffel.org>> wrote: > > > >>>>> "Patrick" == Patrick McEvilly <pmcevilly(a)gmail.com <mailto: > pmcevilly(a)gmail.com>> writes: > > > > Based on a suggestion here we setup Nginx and it looks like it is > > doing what we need but open to other solutions too. We will check > > out rsyslog too. > > > rsyslog should be your goto here, especially since with all those > devices, you might want to filter them into different lots based on > the source IP, etc. > > > > Logs are from about 2500 networking devices including firewall, > > routers, AAA servers, wireless controllers on a sizeable campus > > network. > > > Ok, so are these devices sending only via UDP or can you turn them on > to use TCP? TCP will help keep down message loss, but for your busier > devices, you might run into problems. > > > > We are testing with one firewall and its generating about 7,000 log > > messages a second. This is probably on the high side; some devices > > will be almost zero. > > > I would try using rsyslog in this case. It's certainly easier to > setup than syslog-ng, which was a damn disaster in my book. Super > flexible, lots nad lots of options, but just a total pain in the ass > to get working right. > > > > The hosts are VMs (I will have two) that we are just getting the > > configuration going on, we have not loaded it up with all the logs > > yet so hard to tell CPU usage. Currently it is almost zero. We can > > throw more cpu/memory at it if it is a problem. > > > Make sure you have good networking into these syslog destination VMs. > > > > Having the source send two copies of the same logs is possible > > though now our gear is going to processing more log data than actual > > data __ > > > Sure, makes sense. Nice to just point everything at > 'log.internal.local' and let that system duplicate the data to > multiple destinations or backends. > > > > The real issue if we can't trust the folks we are sending logs to to > > not move or change to another site/location/cloud whoever is on sale > > this week. Keeping some central log boxes makes it so we only have > > to change the target on these two syslog hosts and not on all 2500 > > devices. > > > I understand completely! I'm happy to answer questions and give you > example configs. The docs for rsyslog are ok, but sometimes the > examples are a little lacking for real world examples. Obviously > written by people who know the stuff inside out, but can't write for > smart but ignorant use cases. :-) > > > > > You could also have rsyslog save a copy locally, and then send in to > another host. If you're looking for fully redundant setup, then you > might need a load balancer of some sort. It's hard to get complete > logging without doing funky things because having a fully redundant > setup is nice simple to do right. > > > But also, check your other system configs at the base OS level. And > check your VM's bus drivers. Some network cards will have better > performance than others. Depending on how you have your > virtualization setup, you might need to tweak your VM's hardware setup > to get better network performance. > > > John > > > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists. > wlug.org/ > Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists. > wlug.org/message/ABJGXWV2Z6TKZBGTNEGMOY7UX3LEXPFC/ >

Feb. 8, 2024

Re: Firewalld/iptables/nftables question

by Patrick McEvilly

Our logging folks that operate the $$$$$$syslog server said they were unable to parse our firewall logs once we sent them using tcp. ¯\_(ツ)_/¯ As I indicated in my initial email I'm out over my skis a bit. I'll take a look at rsyslog and see if the docs are dumb enough for my level of skills. Ack on the Host OS, Bus Drivers, etc. We will see how it goes once we load it up. P. On 2/7/24, 5:44 PM, "John Stoffel" <john(a)stoffel.org <mailto:john@stoffel.org>> wrote: >>>>> "Patrick" == Patrick McEvilly <pmcevilly(a)gmail.com <mailto:pmcevilly@gmail.com>> writes: > Based on a suggestion here we setup Nginx and it looks like it is > doing what we need but open to other solutions too. We will check > out rsyslog too. rsyslog should be your goto here, especially since with all those devices, you might want to filter them into different lots based on the source IP, etc. > Logs are from about 2500 networking devices including firewall, > routers, AAA servers, wireless controllers on a sizeable campus > network. Ok, so are these devices sending only via UDP or can you turn them on to use TCP? TCP will help keep down message loss, but for your busier devices, you might run into problems. > We are testing with one firewall and its generating about 7,000 log > messages a second. This is probably on the high side; some devices > will be almost zero. I would try using rsyslog in this case. It's certainly easier to setup than syslog-ng, which was a damn disaster in my book. Super flexible, lots nad lots of options, but just a total pain in the ass to get working right. > The hosts are VMs (I will have two) that we are just getting the > configuration going on, we have not loaded it up with all the logs > yet so hard to tell CPU usage. Currently it is almost zero. We can > throw more cpu/memory at it if it is a problem. Make sure you have good networking into these syslog destination VMs. > Having the source send two copies of the same logs is possible > though now our gear is going to processing more log data than actual > data __ Sure, makes sense. Nice to just point everything at 'log.internal.local' and let that system duplicate the data to multiple destinations or backends. > The real issue if we can't trust the folks we are sending logs to to > not move or change to another site/location/cloud whoever is on sale > this week. Keeping some central log boxes makes it so we only have > to change the target on these two syslog hosts and not on all 2500 > devices. I understand completely! I'm happy to answer questions and give you example configs. The docs for rsyslog are ok, but sometimes the examples are a little lacking for real world examples. Obviously written by people who know the stuff inside out, but can't write for smart but ignorant use cases. :-) You could also have rsyslog save a copy locally, and then send in to another host. If you're looking for fully redundant setup, then you might need a load balancer of some sort. It's hard to get complete logging without doing funky things because having a fully redundant setup is nice simple to do right. But also, check your other system configs at the base OS level. And check your VM's bus drivers. Some network cards will have better performance than others. Depending on how you have your virtualization setup, you might need to tweak your VM's hardware setup to get better network performance. John

Feb. 7, 2024

Re: Firewalld/iptables/nftables question

by John Stoffel

>>>>> "Patrick" == Patrick McEvilly <pmcevilly(a)gmail.com> writes: > Based on a suggestion here we setup Nginx and it looks like it is > doing what we need but open to other solutions too. We will check > out rsyslog too. rsyslog should be your goto here, especially since with all those devices, you might want to filter them into different lots based on the source IP, etc. > Logs are from about 2500 networking devices including firewall, > routers, AAA servers, wireless controllers on a sizeable campus > network. Ok, so are these devices sending only via UDP or can you turn them on to use TCP? TCP will help keep down message loss, but for your busier devices, you might run into problems. > We are testing with one firewall and its generating about 7,000 log > messages a second. This is probably on the high side; some devices > will be almost zero. I would try using rsyslog in this case. It's certainly easier to setup than syslog-ng, which was a damn disaster in my book. Super flexible, lots nad lots of options, but just a total pain in the ass to get working right. > The hosts are VMs (I will have two) that we are just getting the > configuration going on, we have not loaded it up with all the logs > yet so hard to tell CPU usage. Currently it is almost zero. We can > throw more cpu/memory at it if it is a problem. Make sure you have good networking into these syslog destination VMs. > Having the source send two copies of the same logs is possible > though now our gear is going to processing more log data than actual > data __ Sure, makes sense. Nice to just point everything at 'log.internal.local' and let that system duplicate the data to multiple destinations or backends. > The real issue if we can't trust the folks we are sending logs to to > not move or change to another site/location/cloud whoever is on sale > this week. Keeping some central log boxes makes it so we only have > to change the target on these two syslog hosts and not on all 2500 > devices. I understand completely! I'm happy to answer questions and give you example configs. The docs for rsyslog are ok, but sometimes the examples are a little lacking for real world examples. Obviously written by people who know the stuff inside out, but can't write for smart but ignorant use cases. :-) You could also have rsyslog save a copy locally, and then send in to another host. If you're looking for fully redundant setup, then you might need a load balancer of some sort. It's hard to get complete logging without doing funky things because having a fully redundant setup is nice simple to do right. But also, check your other system configs at the base OS level. And check your VM's bus drivers. Some network cards will have better performance than others. Depending on how you have your virtualization setup, you might need to tweak your VM's hardware setup to get better network performance. John

Feb. 7, 2024

Re: Firewalld/iptables/nftables question

by Patrick McEvilly

Hi John Based on a suggestion here we setup Nginx and it looks like it is doing what we need but open to other solutions too. We will check out rsyslog too. Logs are from about 2500 networking devices including firewall, routers, AAA servers, wireless controllers on a sizeable campus network. We are testing with one firewall and its generating about 7,000 log messages a second. This is probably on the high side; some devices will be almost zero. The hosts are VMs (I will have two) that we are just getting the configuration going on, we have not loaded it up with all the logs yet so hard to tell CPU usage. Currently it is almost zero. We can throw more cpu/memory at it if it is a problem. Having the source send two copies of the same logs is possible though now our gear is going to processing more log data than actual data __ The real issue if we can't trust the folks we are sending logs to to not move or change to another site/location/cloud whoever is on sale this week. Keeping some central log boxes makes it so we only have to change the target on these two syslog hosts and not on all 2500 devices. Thanks Patrick On 2/7/24, 4:08 PM, "John Stoffel" <john(a)stoffel.org <mailto:john@stoffel.org>> wrote: >>>>> "Patrick" == Patrick McEvilly via WLUG <wlug(a)lists.wlug.org <mailto:wlug@lists.wlug.org>> writes: > First off, I’m in way over my head. $dayjob we have a redhat 8 box. > We are looking to take in syslog messages and sent them out to > one/two different IP addresses. Were are the syslog messages coming from? And as people have said, rsyslog is quite fast and should have no trouble pushing packets. Is your box running on two seperate interfaces? How fast are they running? How close to saturation are they? I.e. how busy is your networ? > We tried using > https://github.com/sleinen/samplicator <https://github.com/sleinen/samplicator> and while it works perfectly > and a one banana job to setup, we seem to be dropping a significant > amount of traffic on the box. At least 10% of the logs are missing > and we have not loaded up the system yet. We tuned out the network > buffers and added 25MB of memory without any improvement. Are you running in virtual hardware for your RHEL8 box? Looking at samplicator, it's old old software, and might not be tuned for newer versions of linux with sendfile and other system calls to speed things up. You might also have firwall and apparmour and selinux overhead. Try turning them all off. > https://github.com/sleinen/samplicator/issues/72 <https://github.com/sleinen/samplicator/issues/72> > Seems at a high rate of logs (which I think we would fall under) > there seems to be some issues. What is a high rate? > We looked at this option - > https://zapier.com/engineering/iptables-replication/ <https://zapier.com/engineering/iptables-replication/> > Redhat 8 seems to be using firewalld and backended with nfttables so we can’t directly use this > method so we tried this. > firewall-cmd --permanent --direct --add-rule ipv4 mangle PREROUTING 0 -i ens192 -p udp --dport 514 > -j TEE --gateway 127.0.0.1 > firewall-cmd --permanent --direct --add-rule ipv4 nat PREROUTING 1 -i ens192 -p udp --dport 514 -j > DNAT --to-destination 10.137.241.79:514 > firewall-cmd –reload > With no luck, packets are not getting sent to 10.137.241.79. > When it works with samplicator this is what we get. > 11:53:04.382233 IP 10.240.136.4.24277 > 10.240.1.1.syslog: SYSLOG local7.notice, length: 670 > 11:53:04.382408 IP 10.240.136.4.24277 > 10.137.241.79.syslog: SYSLOG local7.notice, length: 697 > sysctl net.ipv4.ip_forward > net.ipv4.ip_forward = 1 > IP Forwarding is enabled. > I’m not at all familiar with any of this and cutting and pasting > from the internet and chatgpt has come up empty. > Anyone have any suggestions on what we are doing wrong? Can you back up and give more details on your setup? Is the traffic coming from a host on the same subnet? Or is the traffic being routed somewhere? I've got rsyslog setup at $WORK and I'm doing all kinds of replication of logs and sending to various places without any problems. I've got probably 10gb of logs per-day going through there. So go back to basics: 1. turn off selinux 2. turn off apparmour 3. give us more details on the source and the destination. 4. Can the source simply send logs to both destinations? 5. How is your CPU on your RHEL8 system? What kind of CPU are you running? John

Feb. 7, 2024

Re: Firewalld/iptables/nftables question

by John Stoffel

>>>>> "Patrick" == Patrick McEvilly via WLUG <wlug(a)lists.wlug.org> writes: > First off, I’m in way over my head. $dayjob we have a redhat 8 box. > We are looking to take in syslog messages and sent them out to > one/two different IP addresses. Were are the syslog messages coming from? And as people have said, rsyslog is quite fast and should have no trouble pushing packets. Is your box running on two seperate interfaces? How fast are they running? How close to saturation are they? I.e. how busy is your networ? > We tried using > https://github.com/sleinen/samplicator and while it works perfectly > and a one banana job to setup, we seem to be dropping a significant > amount of traffic on the box. At least 10% of the logs are missing > and we have not loaded up the system yet. We tuned out the network > buffers and added 25MB of memory without any improvement. Are you running in virtual hardware for your RHEL8 box? Looking at samplicator, it's old old software, and might not be tuned for newer versions of linux with sendfile and other system calls to speed things up. You might also have firwall and apparmour and selinux overhead. Try turning them all off. > https://github.com/sleinen/samplicator/issues/72 > Seems at a high rate of logs (which I think we would fall under) > there seems to be some issues. What is a high rate? > We looked at this option - > https://zapier.com/engineering/iptables-replication/ > Redhat 8 seems to be using firewalld and backended with nfttables so we can’t directly use this > method so we tried this. > firewall-cmd --permanent --direct --add-rule ipv4 mangle PREROUTING 0 -i ens192 -p udp --dport 514 > -j TEE --gateway 127.0.0.1 > firewall-cmd --permanent --direct --add-rule ipv4 nat PREROUTING 1 -i ens192 -p udp --dport 514 -j > DNAT --to-destination 10.137.241.79:514 > firewall-cmd –reload > With no luck, packets are not getting sent to 10.137.241.79. > When it works with samplicator this is what we get. > 11:53:04.382233 IP 10.240.136.4.24277 > 10.240.1.1.syslog: SYSLOG local7.notice, length: 670 > 11:53:04.382408 IP 10.240.136.4.24277 > 10.137.241.79.syslog: SYSLOG local7.notice, length: 697 > sysctl net.ipv4.ip_forward > net.ipv4.ip_forward = 1 > IP Forwarding is enabled. > I’m not at all familiar with any of this and cutting and pasting > from the internet and chatgpt has come up empty. > Anyone have any suggestions on what we are doing wrong? Can you back up and give more details on your setup? Is the traffic coming from a host on the same subnet? Or is the traffic being routed somewhere? I've got rsyslog setup at $WORK and I'm doing all kinds of replication of logs and sending to various places without any problems. I've got probably 10gb of logs per-day going through there. So go back to basics: 1. turn off selinux 2. turn off apparmour 3. give us more details on the source and the destination. 4. Can the source simply send logs to both destinations? 5. How is your CPU on your RHEL8 system? What kind of CPU are you running? John

Feb. 7, 2024

3 million smart toothbrushes were just used in a DDoS attack. Really

by Tim Keller

My favorite part of the story.. "While the details are scarce, we know that the compromised toothbrushes were running Java." We are officially living in the dumbest time line. My only hope is that the servers at the far end of that DDOS attack at least had a minty smell to them.. Tim. -- I am leery of the allegiances of any politician who refers to their constituents as "consumers".

Feb. 7, 2024

Re: Firewalld/iptables/nftables question

by Cara Salter

On 2/6/24 13:11, Patrick McEvilly via WLUG wrote: > All > > First off, I’m in way over my head. $dayjob we have a redhat 8 box. We > are looking to take in syslog messages and sent them out to one/two > different IP addresses. We tried using > https://github.com/sleinen/samplicator > <https://github.com/sleinen/samplicator> and while it works perfectly > and a one banana job to setup, we seem to be dropping a significant > amount of traffic on the box. At least 10% of the logs are missing and > we have not loaded up the system yet. We tuned out the network buffers > and added 25MB of memory without any improvement. What syslog server are you using? In rsyslog at least I'm 99% sure you can send to multiple addresses: *.* @$syslog-receiver:514;RSYSLOG_SyslogProtocol23Format Just duplicating this line should do it. Admittedly, I only have one syslog receiver, but the manpages don't offer any issues with that. The issue it does bring up is with high volumes of logs, where UDP can cause logs to get dropped: > Due to the nature of UDP, you will probably lose some messages in transit. If you expect high traffic volume, you can expect to lose a quite noticeable number of messages (the higher the traffic, the more likely and severe is message loss) (from rsyslogd.conf(5)) I'd take a look at that and see if you even need samplicator. --cs

Feb. 6, 2024

Re: Firewalld/iptables/nftables question

by soup

Haven't used either of those. syslog over tcp will ensure delivery but if volume precludes that use I would use nginx for forwarding UDP if you need something quickly and dirty, but fluentd is kind of made for this. It can do parsing and transforms but it's all modularized with a fairly simple DSL, you can just do forwards. There's a gelf for graylog if that's where you're sending but it'll do s3, stdout, http, etc. https://docs.fluentd.org/how-to-guides/graylog2 There's a mess of how-tos for the popular use cases. good hunting, soup On Tue, Feb 6, 2024 at 1:18 PM Patrick McEvilly via WLUG < wlug(a)lists.wlug.org> wrote: > All > > > > First off, I’m in way over my head. $dayjob we have a redhat 8 box. We > are looking to take in syslog messages and sent them out to one/two > different IP addresses. We tried using > https://github.com/sleinen/samplicator and while it works perfectly and a > one banana job to setup, we seem to be dropping a significant amount of > traffic on the box. At least 10% of the logs are missing and we have not > loaded up the system yet. We tuned out the network buffers and added 25MB > of memory without any improvement. > > > > https://github.com/sleinen/samplicator/issues/72 > > > > Seems at a high rate of logs (which I think we would fall under) there > seems to be some issues. > > > > We looked at this option - > > https://zapier.com/engineering/iptables-replication/ > > > > Redhat 8 seems to be using firewalld and backended with nfttables so we > can’t directly use this method so we tried this. > > > > > > firewall-cmd --permanent --direct --add-rule ipv4 mangle PREROUTING 0 -i > ens192 -p udp --dport 514 -j TEE --gateway 127.0.0.1 > > firewall-cmd --permanent --direct --add-rule ipv4 nat PREROUTING 1 -i > ens192 -p udp --dport 514 -j DNAT --to-destination 10.137.241.79:514 > > firewall-cmd –reload > > > > With no luck, packets are not getting sent to 10.137.241.79. > > > > When it works with samplicator this is what we get. > > > > 11:53:04.382233 IP 10.240.136.4.24277 > 10.240.1.1.syslog: SYSLOG > local7.notice, length: 670 > > 11:53:04.382408 IP 10.240.136.4.24277 > 10.137.241.79.syslog: SYSLOG > local7.notice, length: 697 > > > > sysctl net.ipv4.ip_forward > > net.ipv4.ip_forward = 1 > > > > IP Forwarding is enabled. > > > > I’m not at all familiar with any of this and cutting and pasting from the > internet and chatgpt has come up empty. > > > > Anyone have any suggestions on what we are doing wrong? > > > > Patrick > > > > > > > > > > > > > > > _______________________________________________ > WLUG mailing list -- wlug(a)lists.wlug.org > To unsubscribe send an email to wlug-leave(a)lists.wlug.org > Create Account: https://wlug.mailman3.com/accounts/signup/ > Change Settings: > https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ > Web Forum/Archive: > https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/M2BHG… >

Feb. 6, 2024

Firewalld/iptables/nftables question

by Patrick McEvilly

All First off, I’m in way over my head. $dayjob we have a redhat 8 box. We are looking to take in syslog messages and sent them out to one/two different IP addresses. We tried using https://github.com/sleinen/samplicator and while it works perfectly and a one banana job to setup, we seem to be dropping a significant amount of traffic on the box. At least 10% of the logs are missing and we have not loaded up the system yet. We tuned out the network buffers and added 25MB of memory without any improvement. https://github.com/sleinen/samplicator/issues/72 Seems at a high rate of logs (which I think we would fall under) there seems to be some issues. We looked at this option - https://zapier.com/engineering/iptables-replication/ Redhat 8 seems to be using firewalld and backended with nfttables so we can’t directly use this method so we tried this. firewall-cmd --permanent --direct --add-rule ipv4 mangle PREROUTING 0 -i ens192 -p udp --dport 514 -j TEE --gateway 127.0.0.1 firewall-cmd --permanent --direct --add-rule ipv4 nat PREROUTING 1 -i ens192 -p udp --dport 514 -j DNAT --to-destination 10.137.241.79:514 firewall-cmd –reload With no luck, packets are not getting sent to 10.137.241.79. When it works with samplicator this is what we get. 11:53:04.382233 IP 10.240.136.4.24277 > 10.240.1.1.syslog: SYSLOG local7.notice, length: 670 11:53:04.382408 IP 10.240.136.4.24277 > 10.137.241.79.syslog: SYSLOG local7.notice, length: 697 sysctl net.ipv4.ip_forward net.ipv4.ip_forward = 1 IP Forwarding is enabled. I’m not at all familiar with any of this and cutting and pasting from the internet and chatgpt has come up empty. Anyone have any suggestions on what we are doing wrong? Patrick

Feb. 6, 2024

Re: Hey Everybody! WLUG Meeting this week!

by Tim Keller

Currently we're having issues getting the Turing Pi 2 to boot, so doing a show off of Proxmox I could definitely do as well. I've got a three node setup as well as a backup node running at work, but I don't have anything on it that I couldn't show the world. Tim. On Tue, Feb 6, 2024 at 10:00 AM John Stoffel <john(a)stoffel.org> wrote: > >>>>> "Tim" == Tim Keller via WLUG <wlug(a)lists.wlug.org> writes: > > > We've got a WLUG meeting on the 8th! I know weirdly early in the > > month because the 1st landed on a Thursday! > > > If things go well, I *might* have a Pi cluster using compute cards > > in it! I'll keep you all posted! > > That would be awesome to see. I've finally got ProxMox 8.1.3 up and > running at work. It's an interesting beast with some funky > limitations. And alot of flexibility. But the setup can be tough if > you have VLANs on your trunks/bonds feeding the servers. Lots of by > hand networking setup. > > -- I am leery of the allegiances of any politician who refers to their constituents as "consumers".

Feb. 6, 2024

Re: Hey Everybody! WLUG Meeting this week!

by John Stoffel

>>>>> "Tim" == Tim Keller via WLUG <wlug(a)lists.wlug.org> writes: > We've got a WLUG meeting on the 8th! I know weirdly early in the > month because the 1st landed on a Thursday! > If things go well, I *might* have a Pi cluster using compute cards > in it! I'll keep you all posted! That would be awesome to see. I've finally got ProxMox 8.1.3 up and running at work. It's an interesting beast with some funky limitations. And alot of flexibility. But the setup can be tough if you have VLANs on your trunks/bonds feeding the servers. Lots of by hand networking setup.

Feb. 6, 2024

Hey Everybody! WLUG Meeting this week!

by Tim Keller

Hey Everybody! We've got a WLUG meeting on the 8th! I know weirdly early in the month because the 1st landed on a Thursday! If things go well, I *might* have a Pi cluster using compute cards in it! I'll keep you all posted! As for the meeting details: Time: 7pm Date: 2/8/2024 Location: Techncopia Thanks, Tim. -- I am leery of the allegiances of any politician who refers to their constituents as "consumers".

Feb. 5, 2024

Re: Proxmox!

by Mike Peckar

I am very interested in this topic and also have a conflict most Thursday evenings. I'm curious if folks are using cockpit for virtual management and their impressions. I looked at it a year or two ago and a deal killer in our environment was that it required a browser plug in for that use case on the client side. Mike

Jan. 26, 2024

Re: Proxmox!

by Gregory Boyce

On Fri, Jan 26, 2024 at 4:45 PM John Stoffel <john(a)stoffel.org> wrote: > >>>>> "Gregory" == Gregory Boyce via WLUG <wlug(a)lists.wlug.org> writes: > > > On Thu, Jan 25, 2024, 5:03 PM John Stoffel <john(a)stoffel.org> wrote: > >>>>>> "Gregory" == Gregory Boyce via WLUG <wlug(a)lists.wlug.org> writes: > > >> Coincidentally, I just recently started in a support role at Scale > >> Computing, which provides virtualization leveraging qemu/kvm, with > >> their own proprietary clustered filesystem. > > > Can we convince you to come and give us a talk? This looks really > > interesting! > > > I'm open to giving a talk, but I don't tend to be free on Thursday > > evenings. > > I think we could schedule something if it works better for you. Is > there a particular night that works better? Ideally I'd like to have > you do it in person, if only so I can pick your brain better. > I'm typically free on Mondays and Wednesday evenings, as well as every other Friday. > And does Scale offer support for datastores (not sure the term) on NFS > storage? Since that would make our transistion simpler. > No. We have a proprietary file system that distributes blocks across the cluster. In addition to redundancy of blocks across servers and disks, it also offers tiered storage where the bulk of content will exist on SAS HDDs, with more commonly used blocks moving to SSD or NVME storage. There's some good information here in the linked PDF: https://www.scalecomputing.com/resources/sc-hypercore-scribe-theory-of-oper… The VMs themselves would still be free to make use of any networked filesystems. -- Greg

Jan. 26, 2024

Re: Proxmox!

by John Stoffel

>>>>> "Cara" == Cara Salter via WLUG <wlug(a)lists.wlug.org> writes: > On 1/25/24 17:44, Tim Keller via WLUG wrote: >> Proxmox is it's own linux distro with a customized kernel that focuses >> on kvm. So installing it on a box takes it over. >> I've also setup a proxmox backup server and I'm doing backups of all my >> VMs in 30 minute intervals. >> >> It *feels* a bit like vsphere. The interface is *miles* better than >> OpenStack's interface. > Personally, I'm a fan of XCP-NGs interface over proxmox's. I manage > two clusters (one at home, one in a lab) and one thing that's stuck > out to me is how clunky its authentication is. Manually syncing LDAP > gets kind of old. Could we convinse you to come down to Technocopia and do a presentation too? Dueling presentations! And ideally on the strenths and weaknesses of migrating from VMware. ESX is still the 900lb gorilla, but broadcom certainly seems to be sawing away at the branches underneath it.

Jan. 26, 2024

Re: Proxmox!

by John Stoffel

>>>>> "Gregory" == Gregory Boyce via WLUG <wlug(a)lists.wlug.org> writes: > On Thu, Jan 25, 2024, 5:03 PM John Stoffel <john(a)stoffel.org> wrote: >>>>>> "Gregory" == Gregory Boyce via WLUG <wlug(a)lists.wlug.org> writes: >> Coincidentally, I just recently started in a support role at Scale >> Computing, which provides virtualization leveraging qemu/kvm, with >> their own proprietary clustered filesystem. > Can we convince you to come and give us a talk? This looks really > interesting! > I'm open to giving a talk, but I don't tend to be free on Thursday > evenings. I think we could schedule something if it works better for you. Is there a particular night that works better? Ideally I'd like to have you do it in person, if only so I can pick your brain better. And does Scale offer support for datastores (not sure the term) on NFS storage? Since that would make our transistion simpler.

Jan. 26, 2024

Re: Proxmox!

by William Grenache

Understood - Thank you for that. Bill On Friday, January 26, 2024 at 08:22:54 AM EST, Gregory Boyce via WLUG <wlug(a)lists.wlug.org> wrote: On Fri, Jan 26, 2024 at 7:10 AM William Grenache <grenache7994(a)verizon.net> wrote: Gregory, Looks like Scale Computing competes directly with VxRail (VMware w/ Dell/EMC product) and other HCI appliances - Nutanix AHV comes to mind as well... Although, first glance - looks like you don't need and or can't use the VMware hypervisor in any way. Can I assume Scale has a VM converter? v2v like tools? That's correct. We use the Linux KVM hypervisor rather than working with something like VMWare. You can directly upload vmdk, qcow2, img, vhd and vhdx, and the system will automatically convert them before use if needed. We're natively using qcow2 internally. We also have a partnership with Carbonite for p2v migrations. -- Greg_______________________________________________ WLUG mailing list -- wlug(a)lists.wlug.org To unsubscribe send an email to wlug-leave(a)lists.wlug.org Create Account: https://wlug.mailman3.com/accounts/signup/ Change Settings: https://wlug.mailman3.com/postorius/lists/wlug.lists.wlug.org/ Web Forum/Archive: https://wlug.mailman3.com/hyperkitty/list/wlug@lists.wlug.org/message/FFIM4…

Jan. 26, 2024