- 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