Re: Running FreeBSD on M.2 SSD
On Mon, Feb 24, 2020 at 3:56 PM Mario Olofo wrote: > Hi Matt, > > The ext4 don't have data checksum, but have metadata checksum, which would > probably be corrupted as well, as I reinstalled my Linux over the same > partition the FreeBSD was using, and by > now I have a lot more files on it than I had on FreeBSD. > Mario, Thanks for that clarification; since not all distros necessarily have it based on recency, etc., I didn’t want to assume metadata_csum was enabled, but that’s a positive start. Not as thorough as full data checksumming, but you’re probably right that it’s at least a good baseline to make reasonable judgments about with regard to heavy ext4 use on the same drive. Thanks, — Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Running FreeBSD on M.2 SSD
On Mon, Feb 24, 2020 at 2:44 PM Mario Olofo wrote: > Hi Pete, in the logs there's nothing wrong, I only see the problem on zpool > status after the first scrub, even if I just > reinstall the FreeBSD and some basic packages (didn't even need a lot of > files as I thought). Mario, Out of curiosity, how are you able to tell for sure you aren’t also experiencing corruption under Linux or Windows on the same hardware? Have you been able to run a ZFS scrub using ZFS on Linux? Both default file systems, ext4 and NTFS, are completely unable of letting you know if corruption has occurred — they’ll just corrupt silently — so I’m wondering how you’ve ruled that out. Thanks, — Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: ldapsearch stops working after ~4-12 hours (one host of 4)
On Fri, Dec 27, 2019 at 12:10 PM Lee Damon wrote: > > Both times I observed this: > > : ldapsearch -v -LLL -x -h [redacted].ee.washington.edu -b > dc=ee,dc=washington,dc=edu uid=[redacted] > ldap_initialize( ldap://[redacted].ee.washington.edu ) > ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Do you have connection/access logs on the LDAP server to verify whether a connection is even being established? Also, are you able to try running those same ldapsearch queries with the IP address(es) rather than DNS names for your server? The “can’t contact” initially seems more like potentially DNS resolution or firewall/connectivity than something LDAP related like failure to bind successfully… Thanks, -Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Long-shot: repeatable macOS samba share unmounting during Lightroom import
On Sat, Nov 23, 2019 at 9:34 PM Andrew Reilly wrote: > > The other protagonist in this tale, also connected to the gigabit > LAN, is an iMac running current-Catalina on APFS flash, mounting > three filesystems over SMB, from Samba 4.10.10. After appropriate > Samba tweaking this seems to be at least as reliable as it ever was > with netatalk or NFS, and apparently better supported by Apple. Considering all of the other bugs and instability introduced (or reintroduced) in Catalina: did you have this same Lightroom import workflow configured in Mojave (or whichever other previous macOS version you were using), and if so, were you encountering the same issue? Thanks, — Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: speeding up zfs snapshot listing
Try this instead, should be significantly faster at just displaying snapshots without the sizing info (if that works for your use case): # zfs list -t snapshot -o name -s name Thanks, — Matt Garber On Thu, Nov 14, 2019 at 9:34 AM mike tancsa wrote: > We have a backup server that has a fair amount of zfs snapshots-- > currently at 30,000+... To list them all takes about 20 seconds after > caching, but can take upto a minute after boot up, or if the metadata > has been evicted from ARC. Are there any tunings that can be done to to > speed up the listing or at least make sure the metadata gets cached as > best as possible ? We have a nagios check 4 times a day to make sure > backups are running and fresh that sometimes times out. We will > probably end up close to 50 to 60k worth of snapshots soon. > > The 20 seconds to list, seems to be all CPU bound. Looking at gstat zfs > list -t snapshot is not hitting the disk. So not sure if anything can > be done tuning wise ? > > ---Mike > > ___ > freebsd-stable@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSH error messages (bug id=234793) ) RELENG_12
>>>> Does anyone know what the cause is of this fail message ? >>>> >>>> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234793) >>>> >>>> its triggered by a normal ssh key'd login, but sshd is running with >>>> VERBOSE logging. >>>> >>>> sshd[63290]: Failed unknown for testuser1 from 192.168.xx.yyy port >>>> 60643 ssh2 ? >>>> >>>> The user is able to login no problem, but the error message is bubbling >>>> up in our HIDS. We had to white list it, but it would be useful to >>>> understand exactly why and what is failing. >>>> >>>> —Mike >>> It’s one of the other SSH authentication types (e.g., GSSAPI, password, >>> etc.) which is in the processing order before public key. I’m assuming >>> you’re seeing that ‘failure’ immediately before your successful key >>> authentication in auth.log; I actually had to switch back to INFO for >>> logging because that ‘failure’ trips up sshguard which kicks in and blocks >>> the IP despite the public key auth succeeding right after whichever other >>> auth type is tried and fails. >>> >>> (Unfortunately, I wasn’t able to determine which specific other >>> authentication type was being tried first, since moving logging back to >>> INFO resolved my immediate issue of getting blocked by sshguard before >>> successfully processing my key.) >> I’d also like to point out that whatever authentication method is now being >> tried first was a change from 11.3-RELEASE, as I didn’t encounter that >> ordering issue in my VERBOSE logs triggering sshguard until after upgrading >> to 12.0-RELEASE. I always have password auth disabled (only use public >> keys), but also tried explicit disable statements for GSSAPI and the several >> other auth types I could think of, but unfortunately wasn’t able to >> determine which auth type that log line corresponded to. It could also be an >> auth type that was previously used, but sshd in 12.0-RELEASE re-ordered the >> processing sequence to try it before public keys. > > If you crank it up to debug3, its even stranger. There are a two failed > unknowns, and one is after the key'd authentication has been accepted. > The client I am using, (SecureCRT) has only Public Key auth and has > everything else disabled. > > Oct 18 10:35:35 ryzen-r12 sshd[63439]: debug1: trying public key file > /home/testuser1/.ssh/authorized_keys > Oct 18 10:35:35 ryzen-r12 sshd[63439]: debug3: mm_request_send entering: > type 51 > Oct 18 10:35:35 ryzen-r12 sshd[63439]: debug1: fd 4 clearing O_NONBLOCK > Oct 18 10:35:35 ryzen-r12 sshd[63439]: Failed unknown for testuser1 from > 192.168.43.29 port 63170 ssh2 > Oct 18 10:35:35 ryzen-r12 sshd[63439]: debug1: > /home/testuser1/.ssh/authorized_keys:2: matching key found: RSA > SHA256:xx I think it must be something that the server is trying even if the client doesn’t actually send that type, since I also tested with OpenSSH on the client end (macOS 10.14, OpenSSH_7.9p1, LibreSSL 2.7.3) only specifying public key authentication – with all of its other auth types disabled – and still had the same problem on my upgraded 12.0-RELEASE systems. Thanks, -- Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSH error messages (bug id=234793) ) RELENG_12
> >> Does anyone know what the cause is of this fail message ? >> >> (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234793) >> >> its triggered by a normal ssh key'd login, but sshd is running with >> VERBOSE logging. >> >> sshd[63290]: Failed unknown for testuser1 from 192.168.xx.yyy port >> 60643 ssh2 ? >> >> The user is able to login no problem, but the error message is bubbling >> up in our HIDS. We had to white list it, but it would be useful to >> understand exactly why and what is failing. >> >>—Mike > > It’s one of the other SSH authentication types (e.g., GSSAPI, password, etc.) > which is in the processing order before public key. I’m assuming you’re > seeing that ‘failure’ immediately before your successful key authentication > in auth.log; I actually had to switch back to INFO for logging because that > ‘failure’ trips up sshguard which kicks in and blocks the IP despite the > public key auth succeeding right after whichever other auth type is tried and > fails. > > (Unfortunately, I wasn’t able to determine which specific other > authentication type was being tried first, since moving logging back to INFO > resolved my immediate issue of getting blocked by sshguard before > successfully processing my key.) I’d also like to point out that whatever authentication method is now being tried first was a change from 11.3-RELEASE, as I didn’t encounter that ordering issue in my VERBOSE logs triggering sshguard until after upgrading to 12.0-RELEASE. I always have password auth disabled (only use public keys), but also tried explicit disable statements for GSSAPI and the several other auth types I could think of, but unfortunately wasn’t able to determine which auth type that log line corresponded to. It could also be an auth type that was previously used, but sshd in 12.0-RELEASE re-ordered the processing sequence to try it before public keys. Thanks, -- Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: SSH error messages (bug id=234793) ) RELENG_12
> Does anyone know what the cause is of this fail message ? > > (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234793) > > its triggered by a normal ssh key'd login, but sshd is running with > VERBOSE logging. > > sshd[63290]: Failed unknown for testuser1 from 192.168.xx.yyy port > 60643 ssh2 ? > > The user is able to login no problem, but the error message is bubbling > up in our HIDS. We had to white list it, but it would be useful to > understand exactly why and what is failing. > > —Mike It’s one of the other SSH authentication types (e.g., GSSAPI, password, etc.) which is in the processing order before public key. I’m assuming you’re seeing that ‘failure’ immediately before your successful key authentication in auth.log; I actually had to switch back to INFO for logging because that ‘failure’ trips up sshguard which kicks in and blocks the IP despite the public key auth succeeding right after whichever other auth type is tried and fails. (Unfortunately, I wasn’t able to determine which specific other authentication type was being tried first, since moving logging back to INFO resolved my immediate issue of getting blocked by sshguard before successfully processing my key.) Thanks, -- Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 11-STABLE system unbootable after update
On Sun, May 19, 2019 at 9:00 AM Scott Bennett wrote: > > Many, many thanks to the person who responded with the solution to > get past the > loader crash!! My system is now getting work done again, and the rest of > the new > problems can be dealt with on a running system. Out of curiosity, you mentioned in your previous email you created a new boot environment for this upgrade… since additional issues remain beyond the loader, have you considered rolling back to the known-good BE and attempting the entire process again (with another, separate BE) in a week or so? Especially since that would hopefully allow you to continue your other work without any additional issues or oddities to sort through in the meantime? -- Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On Wed, May 15, 2019 at 11:15 PM Bill Sorenson wrote: > > I’m not sure what you meant about Linux distros not categorizing fixes, > though — with some notable exceptions, most of the big ones certainly tag > security fixes >separately, which is what allows `unattended-upgrades` on > Debian/Ubuntu based systems (and `yum-cron` on RHEL) to work so nicely > automatically as scheduled on > *only* security errata, while leaving all > other types of updates alone for admin intervention. > > My comment about Linux was not in regards to any particular distro, they > all > have interesting policies of varying effectiveness when it comes to release > engineering, but specifically about the Linux kernel team (Torvalds Et al,) > which last I checked had a policy of specifically not handling security > issues > any different from any generic bug. Distros may do their own kernel release > engineering and handling that themselves which is fine. Understood, yep, that historical stance in the kernel itself has really sucked and does no one any favors with ‘everything is just a bug.’ Thankfully the kernel self-protection project has made some significant strides in that area, even if the overall security attitude of maintainers has been slower to positive change than would be ideal. — Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
On Wed, May 15, 2019 at 10:28 PM Bill Sorenson wrote: > > Admins attentive to security issues will already be tracking CVEs for > > the software they use and mitigating or solving the vulnerability by all > > means available. > > > > By batching updates, FreeBSD is making administrative decisions for > > other people's systems. Some folks don't need to worry about scheduling > > downtime and will benefit from faster update availability. Folks who > > need to worry about scheduling downtime are already going to batch > > updates and should be allowed to make those decisions for themselves. > > Batched SAs help in neither case. > > > > Example: the ntpd CVE is more than two months old, and was rapidly fixed > > in ports. I was able to switch my systems to the ports ntpd during a > > scheduled downtime window in March instead of doing it this weekend. So > > not only did I benefit from the faster update availability, I was able > > to make my own decision about my own systems and significantly reduce my > > exposure. > > > > Don't be Microsoft. Don't sit on security updates. > > I'm inclined to agree with this sentiment. I can sort of understand > holding a SA > for a week while waiting for another SA's embargo to end but beyond that I > think > the patches for Security Advisories should be made available as soon as > practical. SysAdmins need to be smart enough to plan updating strategies, > whether they can get away with patching quarterly, monthly, weekly, > immediately, > etc. It depends on the systems and the circumstances. I appreciate the SO's > work, but in my opinion if a patch to a CVE makes it to STABLE it should > be in > the patch branch within a week or so unless issues are discovered (and > depending > on the severity of the issue maybe it should be pushed anyway with > caveats.) > > FreeBSD already makes a distinction between SAs and Errata unlike some > other > projects, I think that should factor into how they are delivered. > Security Advisories should be made available quickly regardless of whether > they > are known the be exploited in the wild or we might as well just go the > Linux > route and call everything a 'bug fix' and not bother categorizing things > at all. I’m certainly not advocating holding on to SAs for an extended period of time, either: if something like the ntpd fix takes a long time to roll out on a consistent basis, maybe that’s rationale for the separate discussion of further shrinking the base system (?), since what’s ‘best’ for the majority of users in that scenario is probably getting that patched via packages/ports in days, not weeks (or months). However, I otherwise don’t find anything objectionable to releasing several ENs or SAs at once, assuming they were close in time anyway. E.g., I think it’s perfectly sane to publish 4-5 advisories/notices at once on a Thursday rather than one on Monday, one on Tuesday, two on Wednesday, etc., especially since we don’t yet have pkg base, and it fits the model of RELEASE-pX to RELEASE-pY bundling those up. I’m not sure what you meant about Linux distros not categorizing fixes, though — with some notable exceptions, most of the big ones certainly tag security fixes separately, which is what allows `unattended-upgrades` on Debian/Ubuntu based systems (and `yum-cron` on RHEL) to work so nicely automatically as scheduled on *only* security errata, while leaving all other types of updates alone for admin intervention. — Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
> On May 15, 2019, at 12:28 PM, Andrea Venturoli wrote: > > On 5/15/19 6:16 PM, Matt Garber wrote: > >> Exactly. If batching 8 (or more) individual bugs/issues together into >> one release is really causing admin/manpower overload and angst,then >> maybe it’s time in your situation to use the binary updates (which >> would only be a single `freebsd-update` and reboot, so there would >> be no ‘sudden unplanned outages’) rather than tracking src and >> remediating each individual bug at a time. > > Maybe I'm dumb, but I still don't get what "src vs binary" has to do with "8 > vs 1"... > I ran a single "svn update; make buildworld; make kernel; make installworld; > reboot", not 8... > > bye > av. Agreed. But if, say, you were tracking specific svn revisions rather than just jumping to the latest, I *guess* it might involve 8 separate builds? I certainly prefer one, batched downtime event to address across all affected systems, regardless of binary updates or src, and I imagine most other individuals/companies/organizations do, too. -- Matt ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD flood of 8 breakage announcements in 3 mins.
> On May 15, 2019, at 12:12 PM, Will Andrews wrote: > > On Wed, May 15, 2019 at 10:45 AM Julian H. Stacey wrote: > >> Batching also means some of these vulnerabilities could have been >> fixed earlier & less of a surge of demand on recipient admins time. >> >> An admin can find time to ameliorate 1 bug, not 8 suddenly together. >> Avoidance is called planning ahead. Giving warning of a workload. >> Like an admin plans ahead & announces an outage schedule for planned >> upgrade. >> >> Suddenly dumping 8 on admins causes overload on admin manpower. >> 8 reason for users to approach admin in parallel & say >> "FreeBSD seems riddled, how long will all the sudden unplanned >> outages take ? Should we just dump it ?" >> Dont want negative PR & lack of management. >> > > What admins prefer 8 downtime events instead of 1? > > —Will. Exactly. If batching 8 (or more) individual bugs/issues together into one release is really causing admin/manpower overload and angst, then maybe it’s time in your situation to use the binary updates (which would only be a single `freebsd-update` and reboot, so there would be no ‘sudden unplanned outages’) rather than tracking src and remediating each individual bug at a time. I understand that might be mutually exclusive with other reasons why you don’t already use binary updates or prefer to track src for the base system, but there are always compromises and trade-offs to everything, and batching seems preferable to any alternatives. You’d seriously want to run reboots across a server fleet every other day for two weeks if there were 8 separate patches staggered out? That’s insanity, and is way more of a PR problem from a ‘should we just dump it’ perspective. You mention ‘announces an outage schedule for planned upgrade’, but that’s really its own form of internal batching – it shouldn’t make any difference if you’re technically pushing 1 or 8 bug/security fixes during that pre-identified period of time: all of your other internal processes like maintaining a test group for detecting regressions, using boot environments (or other storage features) to allow for rollbacks, etc. all continue to work as intended. Any potential negative PR within your company/organization seems like it would be related to how else you’re handling the upgrade process(es), not whether the fixes are batched or not. Whatever other negative things you can say about them, I don’t hear enterprise admins begging that Microsoft/Oracle/whoever would dribble out patches one at a time each week instead of combining them like they do; it seems like it works just fine for everyone else. ¯\_(ツ)_/¯ Thanks, — Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: X11 on Ryzen 2400G?
> On Jan 30, 2019, at 12:57 PM, Phil Norman wrote: > > My understanding is that the driver is likely borrowed from linux, and > (from http://forum.mxlinux.org/viewtopic.php?t=46887) Vega support only > started working with linux kernel 1.19. The /var/log/Xorg.0.log file says > that the amdgpu module was 'compiled for 1.18.4, module version = 18.1.0'. > Does the 1.18.4 refer to a linux kernel version? If so, what's my best > solution here? Should I just wait until the FreeBSD drivers are updated? Is > there anything I can do in the meantime? Just a point of clarification, I think you’re mixing version numbers up a bit: the Linux kernel version discussed in that forum refers to kernel 4.19 (released Oct 22, 2018), not 1.19. The “compiled for 1.18.4” line is referring to the Xorg server version, not a Linux kernel version (there never was a Linux kernel 1.18, it jumped from patches against 1.0 to 1.1.x versions around ~April-May 1994. Depending on where your amdgpu module came from (e.g., if you compiled it yourself), the first thing I’d verify as a starter is that the “compiled for” version actually matches the Xorg server version you have installed via packages/ports/etc. Thanks, — Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Issue with mod_security3
port to add in the integration of ModSecurity3-nginx if you care about that more than keeping up-to-date with nginx source separately, but then you’d have to avoid overwriting the port – YMMV. Thanks, — Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Issue with mod_security3
On Jan 22, 2019, at 1:54 PM, Gregory Byshenk wrote: > > On Tue, Jan 22, 2019 at 11:29:01AM -0500, SoftwareInforJam wrote: > >> I am have a queer problem with the port mod_security3. I >> actually want to set it up to work with NGINX. The port >> /usr/ports/www/mod_security3 exists but when I do a >> # pkg install mod_security3 >> I get >> ???pkg: No packages available to install matching 'mod_security3' >> have been found in the repositories??? >> >> When I do a pkg search ???mod_security*??? only >> ap24-mod_security-2.9.2_3 Intrusion detection and prevention >> engine. So only version 2.9 shows up. Not sure why this is >> happening. Can anyone shed some light on this please? > > I'm no expert on mod_security, but my guess, based on reading > https://www.linuxjournal.com/content/modsecurity-and-nginx, > is that previous (to v3) versions of mod_security worked > _only_ with apache. > > And it seems likely that the port has not yet been updated to > the newest v3. > > Also based on the article, it seems that getting even mod_security > v3 to work with nginx is slightly complicated, as building it > depends on the specific version of nginx that is installed. ModSecurity 3 – working natively with nginx – is significantly different than prior versions, although in this case I think it’s merely a matter of not searching for the correct package name: here are the two packages (not ports) available – note the name change for v3. You’ll need to install ‘modsecurity3’ via packages for that version. (Your search for mod_security* was too restrictive and didn’t show you the v3 package, since it omits the underscore.) $ pkg search mod | grep security ap24-mod_security-2.9.2_3 Intrusion detection and prevention engine modsecurity3-3.0.3_1 Intrusion detection and prevention engine Thanks, — Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Any suggestions for a layer 3 load ablancer for 12, as relayd doesnt work anymore
> On Jan 15, 2019, at 9:43 AM, Pete French wrote: > > Thanks for the suggestions - unfortunately both of those (unless I > misread them) terminate the TCP connection and make a new one to > the backends. I was after something where I can see the original IP > address on the socket. Though I could put a procy in front and add > the headers I suppse, but thats a biut more work as it involves changing > the code. > > Interested in the apache traffic manager - I hadnt come across that > one before, tahnks, Pete, For what it’s worth, HAProxy has the PROXY protocol for exactly the scenario you’re describing; I’ve heard it’s very straightforward and powerful to use, although haven’t had to use it on any of my HAProxy instances which are primarily doing L7. https://www.haproxy.com/blog/preserve-source-ip-address-despite-reverse-proxies/ Thanks, — Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading 11.2 -> 12.0 on EC2
> On Dec 19, 2018, at 1:24 PM, Brian Neal wrote: > > Thanks, Matt. I did try the update procedure from the handbook and found the > instance hanging on boot with a repeated socket error. If I have to rebuild > from scratch, I’d prefer to find some jail/deployment-automation so I don’t > have to manually rebuild everything on each release. FWIW, I did have to > recreate the instance when moving from 10 to 11. I’m assuming that error, ‘sockstat input size mismatch’, was encountered during the very first reboot to the new 12.0 kernel? In that case, perhaps there’s an EC2-specific issue at play, since at that point userland and package updates haven’t even come into the picture yet. I’ve performed several 11.2 -> 12.0 upgrades on Digital Ocean (KVM hypervisor) within the past week without any kernel problems, but in your case the safest choice could simply be new instances, one of the things thankfully made nicest by the various cloud providers. I’d also very much recommend looking into some kind of new system automation to make things easier for you – whether it’s a full-blown official thing like Ansible or Puppet, or even just maintaining a giant shell script which you can use on fresh instances, so you’re not having to re-edit config. files by hand each time. -- Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Upgrading 11.2 -> 12.0 on EC2
> On Dec 19, 2018, at 1:50 AM, Brian Neal wrote: > > I’m looking for advice on doing a release upgrade of a running instance. It > looks like the normal procedure using freebsd-update requires a reboot > between invocations of the install command, but after the first reboot, most > of the userland is non-functional, including most importantly sshd. Is it > safe to run the install commands back to back without rebooting? Or is the > only safe procedure to build a new instance from scratch for each release? Brian, It’s not true that after the first reboot the userland is non-functional; sshd and friends should still be working fine. The first reboot switches you to the 12.0 kernel, which is necessary as the first step before upgrading the userland to 12.0 – and of course potentially using `pkg-static` or ports to rebuild/reinstall your packages/ports against the new ABI. If you’re running any kind of public-facing service, the safest method in my opinion *with as little downtime as possible* is to deploy a new instance and then point to it once everything is successfully reinstalled (e.g., DNS change, elastic IP change, elastic load balancer, etc.). Otherwise, the “safe” method to upgrade in place is to follow what the handbook says, including when to reboot between invocations of `freebsd-update`. As long as you follow exactly when it instructs a reboot, and when to upgrade/reinstall userland and packages/ports, you should be fine. If you’re still nervous, just snapshot your boot EBS volume first as an extra precautionary measure, and destroy it once you verify everything post-upgrade. -- Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: HEADS UP: TCP CUBIC Broken on 12.0-RELEASE/STABLE
On Sun, Dec 16, 2018 at 11:44 AM Kurt Jaeger wrote:
> Will CUBIC be used if the system is running 12.0, or does it only happen
> if one actively configures the use of the algorithm ?
>
> Can the use be detected somehow ?
>
This only happens if someone explicitly configured the use of the alternate
CC: by setting "cc_cubic_load=YES" in loader.conf{.local}, and setting
"net.inet.tcp.cc.algorithm=cubic" in sysctl.conf. These values deviate from
the default FreeBSD use of newreno, so they must have been set by the admin
at some point, either in a previous release that's been upgraded over time
(like my original discovery), or on a fresh 12.0-RELEASE/STABLE box using
some kind of configuration control or manual setup.
Simplistic instructions to check on a running system could use `sysctl
net.inet.tcp.cc.algorithm` and check that return value for 'cubic'; if it
returns 'newreno', it's the default, and if it returns something else
(e.g., 'htcp') they're also unaffected in this particular case. If they are
using cubic, it should either be changed in loader.conf{.local} and
sysctl.conf back to newreno or another CC prior to upgrading to
12.0-RELEASE/STABLE, or they should wait until the Errata Notice is
hopefully released with the reverted change. Otherwise they'll encounter
the same network connection stalls and problems.
--
Thanks,
-Matt Garber
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
HEADS UP: TCP CUBIC Broken on 12.0-RELEASE/STABLE
Hi all: Just a heads-up for those beginning to test or use FreeBSD 12.0-RELEASE or 12/STABLE, the alternate TCP congestion control algorithm CUBIC (cc_cubic) is currently broken and causes complete stalls of certain network traffic (e.g., rsync, git checkouts, etc.), as well as what appears to be erratic behavior even for basic SSH. I first noticed on a Digital Ocean VM upgraded from 11.2-RELEASE, but was then able to consistently reproduce on a fresh 12.0-RELEASE AWS EC2 instance merely by loading and enabling cc_cubic instead of the default CC, newreno. H-TCP (cc_htcp) was also tested, but the problem is isolated to CUBIC. After some discussion on Twitter with Colin Percival, Hiren Panchasara, and others (thank you!), it was determined that the culprit was r331567 which hadn’t been reverted prior to 12.0-RELEASE. For those with custom kernels, reverting that revision in 12/STABLE will fix the problem with cc_cubic (sys/netinet/cc/cc.h, sys/netinet/cc/cc_cubic.c, sys/netinet/cc/cc_cubic.h); for those running GENERIC 12.0-RELEASE kernels, the only immediate workaround is to use newreno or cc_htcp in the meantime. Hiren has already reverted in HEAD (r342127), and an Errata Notice will hopefully be published at some point in January after the holidays. Hope this saves some troubleshooting! — Thanks, -Matt Garber ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
