You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
(196) |
Apr
(142) |
May
(143) |
Jun
(86) |
Jul
(177) |
Aug
(232) |
Sep
(196) |
Oct
(221) |
Nov
(211) |
Dec
(139) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(135) |
Feb
(124) |
Mar
(114) |
Apr
(127) |
May
(173) |
Jun
(184) |
Jul
(70) |
Aug
(140) |
Sep
(188) |
Oct
(146) |
Nov
(127) |
Dec
(178) |
2004 |
Jan
(83) |
Feb
(167) |
Mar
(172) |
Apr
(260) |
May
(210) |
Jun
(156) |
Jul
(64) |
Aug
(65) |
Sep
(116) |
Oct
(177) |
Nov
(156) |
Dec
(88) |
2005 |
Jan
(130) |
Feb
(82) |
Mar
(47) |
Apr
(51) |
May
(99) |
Jun
(80) |
Jul
(59) |
Aug
(57) |
Sep
(86) |
Oct
(40) |
Nov
(24) |
Dec
(14) |
2006 |
Jan
(52) |
Feb
(30) |
Mar
(32) |
Apr
(74) |
May
(35) |
Jun
(55) |
Jul
(79) |
Aug
(35) |
Sep
(32) |
Oct
(18) |
Nov
(27) |
Dec
(30) |
2007 |
Jan
(17) |
Feb
(33) |
Mar
(36) |
Apr
(46) |
May
(6) |
Jun
(15) |
Jul
(16) |
Aug
(10) |
Sep
(22) |
Oct
(21) |
Nov
(43) |
Dec
(25) |
2008 |
Jan
(9) |
Feb
(16) |
Mar
(32) |
Apr
(2) |
May
(3) |
Jun
(27) |
Jul
(23) |
Aug
(19) |
Sep
(5) |
Oct
(18) |
Nov
(15) |
Dec
(8) |
2009 |
Jan
(14) |
Feb
(14) |
Mar
(36) |
Apr
(4) |
May
(23) |
Jun
(5) |
Jul
(7) |
Aug
(44) |
Sep
(50) |
Oct
(16) |
Nov
(20) |
Dec
(67) |
2010 |
Jan
(10) |
Feb
(10) |
Mar
(30) |
Apr
(49) |
May
(104) |
Jun
(74) |
Jul
(32) |
Aug
(12) |
Sep
(16) |
Oct
(41) |
Nov
(26) |
Dec
(61) |
2011 |
Jan
(65) |
Feb
(16) |
Mar
(48) |
Apr
(22) |
May
(39) |
Jun
(15) |
Jul
(102) |
Aug
(43) |
Sep
(70) |
Oct
(87) |
Nov
(47) |
Dec
(25) |
2012 |
Jan
(39) |
Feb
(41) |
Mar
(53) |
Apr
(30) |
May
(22) |
Jun
(37) |
Jul
(42) |
Aug
(62) |
Sep
(26) |
Oct
(56) |
Nov
(33) |
Dec
(40) |
2013 |
Jan
(40) |
Feb
(40) |
Mar
(47) |
Apr
(77) |
May
(70) |
Jun
(50) |
Jul
(22) |
Aug
(22) |
Sep
(19) |
Oct
(24) |
Nov
(46) |
Dec
(27) |
2014 |
Jan
(10) |
Feb
(46) |
Mar
(36) |
Apr
(14) |
May
(27) |
Jun
(67) |
Jul
(59) |
Aug
(85) |
Sep
(13) |
Oct
(50) |
Nov
(9) |
Dec
(8) |
2015 |
Jan
(22) |
Feb
(20) |
Mar
(15) |
Apr
(3) |
May
(1) |
Jun
(17) |
Jul
(21) |
Aug
(1) |
Sep
(4) |
Oct
(13) |
Nov
(22) |
Dec
(25) |
2016 |
Jan
(18) |
Feb
(24) |
Mar
(16) |
Apr
(11) |
May
(21) |
Jun
(8) |
Jul
(12) |
Aug
(7) |
Sep
(36) |
Oct
(14) |
Nov
(20) |
Dec
(8) |
2017 |
Jan
(27) |
Feb
(14) |
Mar
(12) |
Apr
(3) |
May
(3) |
Jun
(13) |
Jul
(6) |
Aug
(1) |
Sep
(1) |
Oct
(25) |
Nov
|
Dec
(18) |
2018 |
Jan
(7) |
Feb
(9) |
Mar
(11) |
Apr
(11) |
May
|
Jun
|
Jul
(10) |
Aug
(2) |
Sep
(4) |
Oct
|
Nov
|
Dec
(1) |
2019 |
Jan
(2) |
Feb
(11) |
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(11) |
Jun
(2) |
Jul
(2) |
Aug
(5) |
Sep
(2) |
Oct
(1) |
Nov
|
Dec
|
2021 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(4) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
(3) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2023 |
Jan
|
Feb
(2) |
Mar
(3) |
Apr
(32) |
May
(7) |
Jun
|
Jul
(2) |
Aug
(3) |
Sep
(11) |
Oct
(12) |
Nov
(10) |
Dec
(5) |
2024 |
Jan
(2) |
Feb
(6) |
Mar
(2) |
Apr
(5) |
May
(1) |
Jun
(8) |
Jul
(4) |
Aug
(3) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
From: Daniel M. <da...@mi...> - 2024-09-24 12:27:12
|
Netatalk stable release versions 3.2.10 and 2.4.10 are available. The releases include these notable fixes: - Fixed bug that caused errors when authenticating with the ClearTxt UAM with shadow passwords. Does not affect PAM. - With the default Meson settings, debugging mode would be enabled which turns off server tickles. This leads to client disconnections after a short idle time. (3.2 only) - Changed the default D-Bus config file installation path from `etc/dbus-1/system.d` to `share/dbus-1/system.d`. This is the cross-platform standard as per at least 2015. (3.2 only.) Full release notes at: https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-10 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-10 Regards, Daniel |
From: Daniel M. <da...@mi...> - 2024-09-16 13:22:29
|
For those of you who have been following along in the GitHub project, you may have seen that we have been working towards a Netatalk 4.0.0 release. The thesis for Netatalk 4.0 is: Keep all the good stuff in Netatalk 3.x, but bring back the AppleTalk transport layer from 2.x. Make Netatalk the ultimate networking suite for new and old Macs alike. Thanks to the efforts of NJRoadfan to restore ASP support for afpd, I now consider 4.0 feature complete. The `main' git branch is henceforth in beta status. I won't be tagging beta releases however. There's also a beta Docker image available: https://hub.docker.com/r/netatalk/netatalk What we brought back from 2.x: - daemons: atalkd, papd, timelord, a2boot - config files: atalkd.conf, papd.conf - other binaries: pap, papstatus, aecho, getzones, nbp* - AppleTalk init scripts for NetBSD and Linux - a handful of afp.conf options: See the Upgrade chapter in the manual https://netatalk.io/4.0/htmldocs/upgrade What we DIDN'T bring back from 2.x: - virtual servers in afpd - SLP service discovery in afpd - CAP style printer auth in papd - PostScript printing tools (psf, psorder, etc.) - sundry other tools: ppdshow, cnid2_create, megatron, uniconv - probably others that I forgot In the coming weeks we will be testing and stabilizing this code! If you find any bugs or have requests, don't hesitate to respond here or file an issue ticket on GitHub. Sincerely, Daniel |
From: Daniel M. <da...@mi...> - 2024-09-15 11:14:43
|
New Netatalk versions 3.2.9 and 2.4.9 are available. These releases contain bugfixes for the DHX2 and DHX UAMs that prevent an intermittent failure when authenticating from a client. Special thanks to Derrik Pates for the report and the patches. https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-9 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-9 At a related note, Derrik is recently improving his venerable AFP client (afp-perl). I also learned that he has created AppleTalk network protocol libraries (atalk-perl). https://github.com/demonfoo/afp-perl https://github.com/demonfoo/atalk-perl Check them out! Sincerely, Daniel |
From: Daniel M. <da...@mi...> - 2024-09-09 11:53:48
|
Netatalk version 3.2.8 and version 2.4.8 are available now. Please find the release notes and tarballs below. https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-8 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-8 These are primarily security patch releases, upgrading the bundled WolfSSL library from v5.7.0 to v5.7.2. It also contains code fixes that allow you to build against a shared WolfSSL v5.7.2 library. See the full WolfSSL v5.7.2 release notes at: https://github.com/wolfSSL/wolfssl/releases/tag/v5.7.2-stable While upgrading the bundled library, we de-forked WolfSSL and restored all its source files to their pristine upstream state. The local modifications were to minimize the library and leave only precisely the symbols that we needed for Netatalk. However, a clean upgrade to v5.7.2 wasn't possible without significant additional work. I believe having a clean upgrade path for WolfSSL is preferable to small amounts of memory optimization. Sincerely, Daniel |
From: Andy L. <and...@gm...> - 2024-09-05 00:11:30
|
<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto">Hi everyone :)<div><br></div><div>I finally found some time to dig through the code regarding this, and I noticed that the afp_dsi code seems to be exclusively related to network socket stuff. I was not familiar with the term DSI, but this gave me enough information to find this page</div><div><div style="display: block;" class=""><div style="-webkit-user-select: all; -webkit-user-drag: element; display: inline-block;" class="apple-rich-link" draggable="true" role="link" data-url="https://en.m.wikipedia.org/wiki/Data_Stream_Interface"><a style="border-radius:10px;font-family:-apple-system, Helvetica, Arial, sans-serif;display:block;-webkit-user-select:none;width:300px;user-select:none;-webkit-user-modify:read-only;user-modify:read-only;overflow:hidden;text-decoration:none;" class="lp-rich-link" rel="nofollow" href="https://en.m.wikipedia.org/wiki/Data_Stream_Interface" dir="ltr" role="button" draggable="false" width="300"><table style="table-layout:fixed;border-collapse:collapse;width:300px;background-color:#E9E9EB;font-family:-apple-system, Helvetica, Arial, sans-serif;" class="lp-rich-link-emailBaseTable" cellpadding="0" cellspacing="0" border="0" width="300"><tbody><tr><td vertical-align="center"><table bgcolor="#E9E9EB" cellpadding="0" cellspacing="0" width="300" style="font-family:-apple-system, Helvetica, Arial, sans-serif;table-layout:fixed;background-color:rgba(233, 233, 235, 1);" class="lp-rich-link-captionBar"><tbody><tr><td style="padding:8px 0px 8px 0px;" class="lp-rich-link-captionBar-textStackItem"><div style="max-width:100%;margin:0px 16px 0px 16px;overflow:hidden;" class="lp-rich-link-captionBar-textStack"><div style="word-wrap:break-word;font-weight:400;font-size:11px;overflow:hidden;text-overflow:ellipsis;text-align:left;" class="lp-rich-link-captionBar-textStack-bottomCaption-leading"><a rel="nofollow" href="https://en.m.wikipedia.org/wiki/Data_Stream_Interface" style="text-decoration: none" draggable="false"><font color="#000000" style="color: rgba(0, 0, 0, 1);">wikipedia.org</font></a></div></div></td><td style="padding:0px 12px 0px 0px;" class="lp-rich-link-captionBar-rightIconItem" width="32"><a rel="nofollow" href="https://en.m.wikipedia.org/wiki/Data_Stream_Interface" draggable="false"><img src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGwAAABsCAQAAAAlb59GAAANBGlDQ1BrQ0dDb2xvclNwYWNlR2VuZXJpY0dyYXlHYW1tYTJfMgAAWIWlVwdck9cWv9/IAJKwp4ywkWVAgQAyIjOA7CG4iEkggRBiBgLiQooVrFscOCoqilpcFYE6UYtW6satD2qpoNRiLS6svpsEEKvte+/3vvzud//fPefcc8495557A4DuRo5EIkIBAHliuTQikZU+KT2DTroHyMAYaAN3oM3hyiSs+PgYyALE+WI++OR5cQMgyv6am3KuT+n/+BB4fBkX9idhK+LJuHkAIOMBIJtxJVI5ABqT4LjtLLlEiUsgNshNTgyBeDnkoQzKKh+rCL6YLxVy6RFSThE9gpOXx6F7unvS46X5WULRZ6z+f588kWJYN2wUWW5SNOzdof1lPE6oEvtBfJDLCUuCmAlxb4EwNRbiYABQO4l8QiLEURDzFLkpLIhdIa7PkoanQBwI8R2BIlKJxwGAmRQLktMgNoM4Jjc/WilrA3GWeEZsnFoX9iVXFpIBsRPELQI+WxkzO4gfS/MTlTzOAOA0Hj80DGJoB84UytnJg7hcVpAUprYTv14sCIlV6yJQcjhR8RA7QOzAF0UkquchxEjk8co54TehQCyKjVH7RTjHl6n8hd9EslyQHAmxJ8TJcmlyotoeYnmWMJwNcTjEuwXSyES1v8Q+iUiVZ3BNSO4caViEek1IhVJFYoraR9J2vjhFOT/MEdIDkIpwAB/kgxnwzQVi0AnoQAaEoECFsgEH5MFGhxa4whYBucSwSSGHDOSqOKSga5g+JKGUcQMSSMsHWZBXBCWHxumAB2dQSypnyYdN+aWcuVs1xh3U6A5biOUOoIBfAtAL6QKIJoIO1UghtDAP9iFwVAFp2RCP1KKWj1dZq7aBPmh/z6CWfJUtnGG5D7aFQLoYFMMR2ZBvuDHOwMfC5o/H4AE4QyUlhRxFwE01Pl41NqT1g+dK33qGtc6Eto70fuSKDa3iKSglh98i6KF4cH1k0Jq3UCZ3UPovfi43UzhJJFVLE9jTatUjpdLpQu6lZX2tJUdNAP3GkpPnAX2vTtO5YRvp7XjjlGuU1pJ/iOqntn0c1biReaPKJN4neQN1Ea4SLhMeEK4DOux/JrQTuiG6S7gHf7eH7fkQA/XaDOWE2i4ugg3bwIKaRSpqHmxCFY9sOB4KiOXwnaWSdvtLLCI+8WgkPX9YezZs+X+1YTBj+Cr9nM+uz/+yQ0asZJZ4uZlEMq22ZIAvUa+HMnb8RbEvYkGpK2M/o5exnbGX8Zzx4EP8GDcZvzLaGVsh5Qm2CjuMHcOasGasDdDhVzN2CmtSob3YUfg78Dc7IvszO0KZYdzBHaCkygdzcOReGekza0Q0lPxDa5jzN/k9MoeUa/nfWTRyno8rCP/DLqXZ0jxoJJozzYvGoiE0a/jzpAVDZEuzocXQjCE1kuZIC6WNGpF36oiJBjNI+FE9UFucDqlDmSZWVSMO5FRycAb9/auP9I+8VHomHJkbCBXmhnBEDflc7aJ/tNdSoKwQzFLJy1TVQaySk3yU3zJV1YIjyGRVDD9jG9GP6EgMIzp+0EMMJUYSw2HvoRwnjiFGQeyr5MItcQ+cDatbHKDjLNwLDx7E6oo3VPNUUcWDIDUQD8WZyhr50U7g/kdPR+5CeNeQ8wvlyotBSL6kSCrMFsjpLHgz4tPZYq67K92T4QFPROU9S319eJ6guj8hRm1chbRAPYYrXwSgCe9gBsAUWAJbeKq7QV0+wB+es2HwjIwDyTCy06B1AmiNFK5tCVgAykElWA7WgA1gC9gO6kA9OAiOgKOwKn8PLoDLoB3chSdQF3gC+sALMIAgCAmhIvqIKWKF2CMuiCfCRAKRMCQGSUTSkUwkGxEjCqQEWYhUIiuRDchWpA45gDQhp5DzyBXkNtKJ9CC/I29QDKWgBqgF6oCOQZkoC41Gk9GpaDY6Ey1Gy9Cl6Dq0Bt2LNqCn0AtoO9qBPkH7MYBpYUaYNeaGMbEQLA7LwLIwKTYXq8CqsBqsHlaBVuwa1oH1Yq9xIq6P03E3GJtIPAXn4jPxufgSfAO+C2/Az+DX8E68D39HoBLMCS4EPwKbMImQTZhFKCdUEWoJhwlnYdXuIrwgEolGMC98YL6kE3OIs4lLiJuI+4gniVeID4n9JBLJlORCCiDFkTgkOamctJ60l3SCdJXURXpF1iJbkT3J4eQMsphcSq4i7yYfJ18lPyIPaOho2Gv4acRp8DSKNJZpbNdo1rik0aUxoKmr6agZoJmsmaO5QHOdZr3mWc17ms+1tLRstHy1ErSEWvO11mnt1zqn1an1mqJHcaaEUKZQFJSllJ2Uk5TblOdUKtWBGkzNoMqpS6l11NPUB9RXNH2aO41N49Hm0appDbSrtKfaGtr22iztadrF2lXah7QvaffqaOg46ITocHTm6lTrNOnc1OnX1df10I3TzdNdortb97xutx5Jz0EvTI+nV6a3Te+03kN9TN9WP0Sfq79Qf7v+Wf0uA6KBowHbIMeg0uAbg4sGfYZ6huMMUw0LDasNjxl2GGFGDkZsI5HRMqODRjeM3hhbGLOM+caLjeuNrxq/NBllEmzCN6kw2WfSbvLGlG4aZpprusL0iOl9M9zM2SzBbJbZZrOzZr2jDEb5j+KOqhh1cNQdc9Tc2TzRfLb5NvM2834LS4sIC4nFeovTFr2WRpbBljmWqy2PW/ZY6VsFWgmtVludsHpMN6Sz6CL6OvoZep+1uXWktcJ6q/VF6wEbR5sUm1KbfTb3bTVtmbZZtqttW2z77KzsJtqV2O2xu2OvYc+0F9ivtW+1f+ng6JDmsMjhiEO3o4kj27HYcY/jPSeqU5DTTKcap+ujiaOZo3NHbxp92Rl19nIWOFc7X3JBXbxdhC6bXK64Elx9XcWuNa433ShuLLcCtz1une5G7jHupe5H3J+OsRuTMWbFmNYx7xheDBE83+566HlEeZR6NHv87unsyfWs9rw+ljo2fOy8sY1jn41zGccft3ncLS99r4lei7xavP709vGWetd79/jY+WT6bPS5yTRgxjOXMM/5Enwn+M7zPer72s/bT+530O83fzf/XP/d/t3jHcfzx28f/zDAJoATsDWgI5AemBn4dWBHkHUQJ6gm6Kdg22BecG3wI9ZoVg5rL+vpBMYE6YTDE16G+IXMCTkZioVGhFaEXgzTC0sJ2xD2INwmPDt8T3hfhFfE7IiTkYTI6MgVkTfZFmwuu47dF+UTNSfqTDQlOil6Q/RPMc4x0pjmiejEqImrJt6LtY8Vxx6JA3HsuFVx9+Md42fGf5dATIhPqE74JdEjsSSxNUk/aXrS7qQXyROSlyXfTXFKUaS0pGqnTkmtS32ZFpq2Mq1j0phJcyZdSDdLF6Y3ZpAyUjNqM/onh01eM7lriteU8ik3pjpOLZx6fprZNNG0Y9O1p3OmH8okZKZl7s58y4nj1HD6Z7BnbJzRxw3hruU+4QXzVvN6+AH8lfxHWQFZK7O6swOyV2X3CIIEVYJeYYhwg/BZTmTOlpyXuXG5O3Pfi9JE+/LIeZl5TWI9ca74TL5lfmH+FYmLpFzSMdNv5pqZfdJoaa0MkU2VNcoN4J/SNoWT4gtFZ0FgQXXBq1mpsw4V6haKC9uKnIsWFz0qDi/eMRufzZ3dUmJdsqCkcw5rzta5yNwZc1vm2c4rm9c1P2L+rgWaC3IX/FjKKF1Z+sfCtIXNZRZl88sefhHxxZ5yWrm0/OYi/0VbvsS/FH55cfHYxesXv6vgVfxQyaisqny7hLvkh688vlr31fulWUsvLvNetnk5cbl4+Y0VQSt2rdRdWbzy4aqJqxpW01dXrP5jzfQ156vGVW1Zq7lWsbZjXcy6xvV265evf7tBsKG9ekL1vo3mGxdvfLmJt+nq5uDN9VsstlRuefO18OtbWyO2NtQ41FRtI24r2PbL9tTtrTuYO+pqzWora//cKd7ZsStx15k6n7q63ea7l+1B9yj29OydsvfyN6HfNNa71W/dZ7Svcj/Yr9j/+EDmgRsHow+2HGIeqv/W/tuNh/UPVzQgDUUNfUcERzoa0xuvNEU1tTT7Nx/+zv27nUetj1YfMzy27Ljm8bLj708Un+g/KTnZeyr71MOW6S13T086ff1MwpmLZ6PPnvs+/PvTrazWE+cCzh0973e+6QfmD0cueF9oaPNqO/yj14+HL3pfbLjkc6nxsu/l5ivjrxy/GnT11LXQa99fZ1+/0B7bfuVGyo1bN6fc7LjFu9V9W3T72Z2COwN358OLfcV9nftVD8wf1Pxr9L/2dXh3HOsM7Wz7Kemnuw+5D5/8LPv5bVfZL9Rfqh5ZParr9uw+2hPec/nx5MddTyRPBnrLf9X9deNTp6ff/hb8W1vfpL6uZ9Jn739f8tz0+c4/xv3R0h/f/+BF3ouBlxWvTF/tes183fom7c2jgVlvSW/X/Tn6z+Z30e/uvc97//7fCQ/4Yk7kYoUAAAB4ZVhJZk1NACoAAAAIAAUBEgADAAAAAQABAAABGgAFAAAAAQAAAEoBGwAFAAAAAQAAAFIBKAADAAAAAQACAACHaQAEAAAAAQAAAFoAAAAAAAAA2AAAAAEAAADYAAAAAQACoAIABAAAAAEAAABsoAMABAAAAAEAAABsAAAAAOIX6z4AAAAJcEhZcwAAITgAACE4AUWWMWAAAAAcaURPVAAAAAIAAAAAAAAANgAAACgAAAA2AAAANgAABRSxLH/cAAAE4ElEQVR4AexZTWgVVxT+3suPbTXE1KSQ5vmz0o0krbTWgtpuEmk20kb8W1hNWim66FoaKWiNG6VFpVUpSLJo04okC0VdiAoGxIVoREgoBGqjEmhjjNG0Ic30zJk7983MvcOb9+ZO3cy8xdw59zvf+bl37j1zH5BeaQbSDKQZSDOQZiDNQJqBNANpBtIMpBlIM5BmIM1AmoFEMpDBSuxEF85hEA8xCYt+k9QaJEkX9axEJhG7CZK+jnb8jDEOxQ4n7DeGXkIuStATY9RZtKIfM6Gh6EKcIY1WZI35YJyoHJ9iyBfSOC7gMHZgHVagFjX0W0YTcC1JDlPPXz7sEE3OcuM+GSBswbDH0UF04u0Co5AlxFe449EaRosBTwxS5PCrdG8aJ/FWUdxN+AHTUv8sckVpJwhuwxPh1jMcRX2oJfv9CrvqSfOZYHmCTWGw/08+D8dlrrs9Qb2icUEf2AKJrEc35gTbccyT8pfQqMUN4cgomj32f6T9Sp1QusCWYArHPJrNGBWMA7TcvKQrJ9fAy6jz+dBDzh3wSewHXWBdJD3jQ9bhkghtSJMcHzSZhxxGhAMHlApiDfU8QmXAsBpYJW/i7wZwGUqKjbXIgjruAbDpxzqxuM9ij5b6Nrm1OdAzRTL/tZ0kt/wi8bQHs9RnkRX/XNCCzQkrcZPNzirOuzY+p/5r7kPo3X5Dd4X0bhah3VRGPkTBhNhZCeeognCuVxXS+fgdpwpUEhWE+AOqrku2Q6yRJ1xB0vc2Hi2LagvnOoR7mglTFsmNCgVViS2yYukUltoUVAKCBkywuT6xZFRxUaQLrRTjK2iSN0nFDPrY1gQWS1lijbNs6gEVtO5VZyy0DtrVulxavtfgAdu74JMm8LCBzcz5tmPQVmqXsvFGrYbrzWEEa5Zm8aZtTCAaSZkVW3KPlLgNO7T7npLKlUe9r6fFxqIQPtQo2Nu9RZajvbUagsKirWxiCg0aaK1mAdHANKJy2pCdXeu0phdkzd4BLWzT9hoQZui0wjbgfwviEi/DALNadBqyMITMLrwssp7QGclHTP/CaHG6DU9FWBY+CQnLfodfMKo1FBGro5fJv4/F4VWuos8UeySc3zlvl9I+waheRW5AUC2+chuZ6zR68H4s1tX4TQZl0afqmxq2tfgJTt3RyNhpVGtQMUXtTH2XWarE1LiNzzC/BN4s9gVOsnYHWBbgC95CLIyLWvEu228P4Aw8OjXAfsGUw0E8ZlOjBSpC1XQDrrCmOwktXA8sCxX00WP3juJrOZL7WdKn0sWTlIlzjVUemgqq6q76vn89naHNj/FnIKxpLFfQZyj4Nl/KVrHWhOndrIlpx2V5mvekmG3zNTqPyo+T29qXJ5Mt9YQxK84h85WkBMdpdLBDF+NQoJFqEzeY/P0O1Apfb+Yia3foO0uVfsekR0pVp3foS/ytCWsW70TmPML630bGRwKeZ9Lg2hVJlUDv4RdNUPaoHY1KQbjdzHG+CI0IUGex/SACUoW8QUc2A3iuCW2kqM1iPTM4G45qpUSJs7Srq1cUun7a2vvxDf5RQmuJoi4xy1n/kXw20nD+tqstgWsXHaJtwBIspRMS95zXWTq6i2RbxIFNFqlVAO644hQ0+RXt3wJaoHCe0nvkVOUZ7PWM2VjBP/yCdqqFdkGjNuA/AAAA//811nvAAAAFPElEQVTtWW1oVWUc/92r220WrOlGTTdbH4rINUso+zCiQE1DiNBlQqPaxhD6JAV9UCuK5ocGlb1YIZGDYpG1kqkgVAS9SGU6ixiLhMWYWa3mNKdr7PZ7/ue5957Xe55z793ywzkD7zn/5/f7/V+ec543AbMrDfVXJWDrXv07HkJO4lOcQa1GJVCGZ0VHcTeHcJFFZvxUaUsoMQpgQkSXRqEQu5WsB1yc10Sp32U1eVwqzAkTqDnmlIjeZE4g8kacxzsuRgp34SjOIWqJlEyjxDDqUizycUBE74ygUoZvMYKFLkaKqf6JT1xWs8c7JIYBM7Apql9EO03hxD1DxhoXfhm+xjS6UeGymz12SgyFvMR59F8U0e48CGfTbZjC6w5TJd6ixo9Y6bBGeeiWGF6IQgnHtovooXCgICowiJ9xuQ29DsP4l2NiymaLentIYmiPSsuPXy6iY0h6YOUeC7ALF3F71r5Q+uoYbs5awm/meyBJjEkMyz0tRRnmcc5Ss88Km0qKc9EXeMNmsW5X8Tt6Kmu9D6dxAdvhDTUL8bnZi8+wifNe7loh/scxL2cqzV2fCO/QYg3oYsAq1WFXL15Jy3ew+rEG7zHJI1gWMYQKrX2KL2+d5u4Qb30RlQzgbSJsDbYVOCtP36DNM8L18JW5QfQ24nfOZI8VVOMFaMf34mMcl4nacXlqM4g0IqQSkyLdJLzd/G5u9VHYwB7aSvtV2E/057jOB2NuWokePC/wJvE9iUpzsjmyV8RfzUO4Gn/gML+mh/AbJvCo6yXNQwxtekV894biCgKsE/HzqA5k7+ertwYfE3cYDYGo6A3V+Ed83xOdasJI4ITIdwWAO9j6E9eB4+hAIgBTmPk58XuixKq2WDaLg3NYbLNlbq/ly6dGyX4syZgi/y5BjQ9nMYtlttHxIZuZklxRKBd7PfAkB4o0x8MHPS3mhmvwC5dc3tR6xOdgQaOrsfe14mQGq12Mx2nfx7GwmKsax6jiTm01ZsTnvcVIm3DfFzfDejdtMRo5KW80IYdgrNR+sPVaFX4VfwdCmCVoruNmX72OfdlPuZyT8KISKCuJTGoLRC+BD8XXGdSXSD+vTKs4S3P9Z13ehbGym63jvStIldoTWnm79lTMl6ulzH72iMMZtAbCr+Bq782Qz72M64pRWH1jF8rsF1r117XH3ji79ykubNXrOI37AxxtYWv4AYAaSTsCFFqornwcMez7AJmo5hoMidtpbPGlqjOSDa4WFabz2kTLUadJP3XqtIZsA4kvsPTGOpyU1NJ4OjuMZLw0s2XEswPzJlbOVzFt25Ja/AQVFTZND3UZybn8rdfTdRoHXXV9l0E96QnFmxjkANU53dfggE5rcG7GQk+cNFTjSx3EiGPK3sX1Yub8N8fzS6wef+GlHASr2NNWb32VZ7FtI8zWbQov60BmuNDKJeN3wOaXGPReW8VXi7f1OJimqtl0MVt5iW4L/tbJneW2MJec26laygZdtWRau3J1Ut8SBJtrez2shZbqk0nshrXLNo2iiQxrd674+/6/L8s/4Lv1BGB9IcexDbd4RksnM0HENlhnGRZrCGudkEvjaT4eyY6TVqBjHOG6uD5pxvUcCqr418ATq2ZauthinRNayDSZbZ4J4tLIS6JIYj0+4vF2JlyT3yky1pfwfGQWy7GIC6VefTaYL7XTPHfsKNnOYBYTckon+D9aD2MnPuBZyagcx0xx1jqJAVp2sqUx5Bt0qsVPcQXiCsQViCsQVyCuQFyBuAJxBeIKxBWIKxBXIK5AXAHzCvwH9WAIYRB4imoAAAAASUVORK5CYII=" draggable="false" style="pointer-events:none !important;display:inline-block;width:32px;height:32px;" class="lp-rich-link-captionBar-rightIcon" width="32" height="32" data-unique-identifier=""></a></td></tr></tbody></table></td></tr></tbody></table></a></div></div><br></div><div>This page clarified that DSI stands for “Data Stream Interface” and is a network socket/message protocol created by Apple for AFP 👍</div><div><br></div><div>As such, I now understand the DSI buffer is in fact a data buffer to keep the network pipe full (due to the disparity between a network‘s fast and small packet exchanges, versus storage’s high latency and large IO).</div><div><br></div><div>So my previous assertion that the buffer was a storage IO buffer was wrong, and it is a network IO buffer - Ie, it should be just large enough to keep the network link full.</div><div><br></div><div>The documentation says ‘dsireadbuf’ is a ‘readahead’ buffer however, which is confusing as a ‘readahead’ buffer is usually a storage IO feature to improve throughput associated with the high latency of spinning disks.</div><div><br></div><div>Could someone please be so kind and explain to me what is meant by ‘readahead’ in the context of this network buffer?</div><div><br></div><div>My original comments about read-amplification risks are likely wrong as I do not see any readahead functionality at all here?</div><div><br></div><div>Ie, if Netatalk is not performing any application layer readahead then there is no read amplification risk on intelligent filesystems like ZFS which read in front of streaming read operations.</div><div><br></div><div>Thanks again for your time and thoughts.</div><div>Andy</div><div><div dir="ltr"><br></div><div dir="ltr"><br><blockquote type="cite">On 30 Jul 2024, at 13:22, Andrew Lemin <and...@gm...> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr">Hi Netatalk Admins! :)<div><br></div><div>I have been chatting to rdmark@ recently, and initially raised this topic as a documentation improvement request. He suggested I include the community for a broader discussion, so here goes..</div><div>Original; <a href="https://github.com/Netatalk/netatalk/discussions/1344">https://github.com/Netatalk/netatalk/discussions/1344</a><br></div><div><br></div><div>Since FreeBSD 14.1 (net stack improvements & CUBIC) <a class="gmail_plusreply" id="plusReplyChip-0">+</a> Netatalk 3.2.x (code clean up & WolfSSL) <a class="gmail_plusreply" id="plusReplyChip-1">+</a> OpenZFS 2.2.x (many notable improvements, inc prefetch changes), you can now easily saturate a storage array via Netatalk shares over 10GbE. Netatalk with above, is also on average 20-30% faster than Samba 4.19.x on the same. </div><div><br></div><div>As a result, I believe this topic is now quite pertinent.</div><div><br></div><div><p dir="auto" style="box-sizing:border-box;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px;margin-top:0px"><strong style="box-sizing:border-box">Is your feature request related to a problem? Please describe.</strong><br style="box-sizing:border-box">Desire to tune Netatalk disk IO for better interoperability with ZFS</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><strong style="box-sizing:border-box">Describe the solution you'd like</strong><br style="box-sizing:border-box">The default values for <code class="gmail-notranslate" style="box-sizing:border-box;font-size:11.9px;padding:0.2em 0.4em;margin:0px;border-radius:6px">server quantum</code>(1MB) and <code class="gmail-notranslate" style="box-sizing:border-box;font-size:11.9px;padding:0.2em 0.4em;margin:0px;border-radius:6px">dsireadbuf (x12)</code>(according to the manual), implies that Netatalk will read-ahead up-to 12MB when it detects sequential reads as a prefetch mechanism.</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">I believe (maybe naively), that <code class="gmail-notranslate" style="box-sizing:border-box;font-size:11.9px;padding:0.2em 0.4em;margin:0px;border-radius:6px">server quantum</code> roughly equates to the OpenZFS <code class="gmail-notranslate" style="box-sizing:border-box;font-size:11.9px;padding:0.2em 0.4em;margin:0px;border-radius:6px">recordsize</code>. And <code class="gmail-notranslate" style="box-sizing:border-box;font-size:11.9px;padding:0.2em 0.4em;margin:0px;border-radius:6px">dsireadbuf</code> roughly equates to the OpenZFS sysctl <code class="gmail-notranslate" style="box-sizing:border-box;font-size:11.9px;padding:0.2em 0.4em;margin:0px;border-radius:6px">vfs.zfs.prefetch.max_distance</code>.</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">So we have prefetching in multiple layers resulting in double prefetch.</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">If Netatalk detects a sequential read, it should reach a high value for dsireadbuf quickly? (I assume it grows the longer the sequential read lasts).<br style="box-sizing:border-box">OpenZFS will in-turn observe Netatalk's read-ahead and will itself also start reading ahead, in front of Netatalks read-ahead.</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">OpenZFS by default reads ahead upto 64MB, therefore there is a risk of read amplification?</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><strong style="box-sizing:border-box">Describe alternatives you've considered</strong><br style="box-sizing:border-box">In the case of Netatalk on an intelligent filesystem like ZFS, is it better to reduce <code class="gmail-notranslate" style="box-sizing:border-box;font-size:11.9px;padding:0.2em 0.4em;margin:0px;border-radius:6px">dsireadbuf</code> and allow ZFS to perform the read ahead instead (considering it knows the block layout)? - I believe yes.</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">And should <code class="gmail-notranslate" style="box-sizing:border-box;font-size:11.9px;padding:0.2em 0.4em;margin:0px;border-radius:6px">server quantum</code> be set to match ZFS recordsize? - I believe this is not important and likely to have undesirable side effects.</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px"><strong style="box-sizing:border-box">Additional context</strong><br style="box-sizing:border-box">The default values (12MB read head for Netatalk and 64MB for ZFS) work great for large files, and provide peak speed easily. But latency can suffer, especially with small files.</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">In my own testing, reducing <code class="gmail-notranslate" style="box-sizing:border-box;font-size:11.9px;padding:0.2em 0.4em;margin:0px;border-radius:6px">dsireadbuf</code> to 2 or 4 has zero impact on reading large files (can still saturate 10GbE), but has a small benefit for reading small files. Most notably, it seems to improve parallel IO performance during Netatalk reads (I assume reduces latency for other ops because the disks are spending less time on wasted reads, allowing time for other IO operations).</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">This is observational, and I have no empirical evidence as it is hard to measure the respective buffers in each layer etc. I do notice that MRU (Most Recently Used) ARC evictions can get high, which usually means prefetched blocks in ZFS ARC were never read. This can indicate wasted prefetching. But again it is too hard to test and prove this is due to the Netatalk IO and nothing else..</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px">Therefore I am looking for discussion and additional context for Netatalk's `server quantum` and `dsireadbuf` parameters to help justify or dismiss this tuning idea for Netatalk on OpenZFS.</p><p dir="auto" style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px;margin-bottom:0px">Thanks in advance for your thoughts.</p><p style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px;margin-bottom:0px">Andy Lemin</p><p style="box-sizing:border-box;margin-top:0px;color:rgb(31,35,40);font-family:-apple-system,"system-ui","Segoe UI","Noto Sans",Helvetica,Arial,sans-serif,"Apple Color Emoji","Segoe UI Emoji";font-size:14px;margin-bottom:0px"><br></p></div></div> </div></blockquote></div></body></html> |
From: Daniel M. <da...@mi...> - 2024-08-19 14:18:53
|
Netatalk 3.2.7 and 2.4.7 are available. They constitute another pair of Meson build system bug fix releases. This round of fixes came out of the effort of packaging Netatalk for Arch Linux. https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-7 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-7 A notable change here is that the ld.so.conf.d config file (for the run-time linker on Linux) that was added in the previous versions will no longer be installed by default, and can instead be controlled with a new build system option "-Dwith-ldsoconf". Additionally, default for Meson is to build with RPATH enabled, while disabling the installation of the run-time linker config file. This is in order to provide an end-user default that is able to find the shared libatalk.so library on Linux, without imposing a global run-time linker configuration that could have side effects. Please report any bugs or feature requests! Best regards, Daniel |
From: Daniel M. <da...@mi...> - 2024-08-11 13:11:48
|
Netatalk 3.2.6 and 2.4.6 are available. The notable common improvement in these releases, is that the Meson build system will automatically update the dynamic linker cache when installing netatalk on Linux. Without updating the cache, a glibc based Linux OS may not be able to find the shared libatalk.so library, depending on where you have installed it. This is something that Autotools does automatically, so this change brings parity between the build systems. https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-6 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-6 Also of note in particular to downstream packagers: The html manual pages will now be installed into a `htmldocs' subdir of doc/netatalk rather than in its root. And on 3.2, the Japanese html manual won't be built by default anymore, but has to be enabled with a new `-Dwith-manual-l10n=ja' option. Please respond to this email or file an issue ticket if you find any bugs or have any questions! All the best, Daniel |
From: Daniel M. <da...@mi...> - 2024-08-02 06:48:56
|
A pair of Netatalk bugfix releases are available: 3.2.5 and 2.4.5. As has been the theme with these release series, they contain a range of improvements to the Meson build system. Thanks to the hard work of Andrew Bauer, Fedora RPM packaging has now been achieved with Meson. https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-5 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-5 The most notable change in these versions, is a move to the standard Meson `library()' target. Before this change, the Meson build system was hard coded to build both static and shared libraries. After this change, it has become sensitive to the platform default, controlled through the `-Ddefault_library' build system parameter. In practice, on all supported platforms, the build system will now only build shared libraries by default. For the full changelog, please see the release notes linked above. Again, a huge thanks to the community for finding bugs and doing downstream packaging! We couldn't be doing this without you all. Best regards, Daniel |
From: Andrew L. <and...@gm...> - 2024-07-30 03:22:36
|
Hi Netatalk Admins! :) I have been chatting to rdmark@ recently, and initially raised this topic as a documentation improvement request. He suggested I include the community for a broader discussion, so here goes.. Original; https://github.com/Netatalk/netatalk/discussions/1344 Since FreeBSD 14.1 (net stack improvements & CUBIC) + Netatalk 3.2.x (code clean up & WolfSSL) + OpenZFS 2.2.x (many notable improvements, inc prefetch changes), you can now easily saturate a storage array via Netatalk shares over 10GbE. Netatalk with above, is also on average 20-30% faster than Samba 4.19.x on the same. As a result, I believe this topic is now quite pertinent. *Is your feature request related to a problem? Please describe.* Desire to tune Netatalk disk IO for better interoperability with ZFS *Describe the solution you'd like* The default values for server quantum(1MB) and dsireadbuf (x12)(according to the manual), implies that Netatalk will read-ahead up-to 12MB when it detects sequential reads as a prefetch mechanism. I believe (maybe naively), that server quantum roughly equates to the OpenZFS recordsize. And dsireadbuf roughly equates to the OpenZFS sysctl vfs.zfs.prefetch.max_distance. So we have prefetching in multiple layers resulting in double prefetch. If Netatalk detects a sequential read, it should reach a high value for dsireadbuf quickly? (I assume it grows the longer the sequential read lasts). OpenZFS will in-turn observe Netatalk's read-ahead and will itself also start reading ahead, in front of Netatalks read-ahead. OpenZFS by default reads ahead upto 64MB, therefore there is a risk of read amplification? *Describe alternatives you've considered* In the case of Netatalk on an intelligent filesystem like ZFS, is it better to reduce dsireadbuf and allow ZFS to perform the read ahead instead (considering it knows the block layout)? - I believe yes. And should server quantum be set to match ZFS recordsize? - I believe this is not important and likely to have undesirable side effects. *Additional context* The default values (12MB read head for Netatalk and 64MB for ZFS) work great for large files, and provide peak speed easily. But latency can suffer, especially with small files. In my own testing, reducing dsireadbuf to 2 or 4 has zero impact on reading large files (can still saturate 10GbE), but has a small benefit for reading small files. Most notably, it seems to improve parallel IO performance during Netatalk reads (I assume reduces latency for other ops because the disks are spending less time on wasted reads, allowing time for other IO operations). This is observational, and I have no empirical evidence as it is hard to measure the respective buffers in each layer etc. I do notice that MRU (Most Recently Used) ARC evictions can get high, which usually means prefetched blocks in ZFS ARC were never read. This can indicate wasted prefetching. But again it is too hard to test and prove this is due to the Netatalk IO and nothing else.. Therefore I am looking for discussion and additional context for Netatalk's `server quantum` and `dsireadbuf` parameters to help justify or dismiss this tuning idea for Netatalk on OpenZFS. Thanks in advance for your thoughts. Andy Lemin |
From: Daniel M. <da...@mi...> - 2024-07-20 04:28:38
|
Another synchronized pair of Netatalk releases is now available: 3.2.4 and 2.4.4 These constitute another round of build system bugfixing and improvement. The impetus was again Debian deb packaging. I spotted a few discrepancies in the behavior and resulting packaged files between Autotools and Meson. https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-4 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-4 Most notably, the libatalk ABI versions / soversions are now synchronized between the branches and build systems: 3.2.x - "18.0.0" 2.4.x - "0.0.0" Please let me know if there is something wrong about how the soversions are defined here, that breaks packaging from you. I'm working from the assumption that emulating the behavior of Autotools will lead to the desired outcome... Thanks again for all your feedback and bug reports! Daniel |
From: Daniel M. <da...@mi...> - 2024-07-15 09:17:30
|
New releases from the 3.2 and 2.4 release series are available: 3.2.3 and 2.4.3. These are solely Meson build system bug fix releases. If the Meson build system already works for you, consider this an optional upgrade. With one exception, I was able to complete Debian packaging with these versions, and pass all Lintian validations. https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-3 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-3 The exception is the lack of an override for pkgconfdir in 3.2, which I had to hotfix in the Debian package. If you rely on a pkgconfdir that is not defined as "prefix / sysconfdir" (which is the case for Debian) and have yet to start the transition, you may want to wait for 3.2.4. I have a fix ready in the main branch. Beyond this, I don't see any obstacles to transitioning to the Meson build system fully now. As a reminder, we have these resources to help you get started with the new build system: https://netatalk.io/stable/htmldocs/compile https://github.com/Netatalk/netatalk/blob/main/INSTALL.md Please let us know if you have any feedback or bug reports! Best, Daniel |
From: Daniel M. <da...@mi...> - 2024-07-06 06:59:25
|
Bug fix Netatalk releases 3.2.2 and 2.4.2 are available now. You can find the release notes and tarballs at: https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-2 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-2 TL;DR; If you package a downstream binary package of Netatalk, use the Meson build system with the bundled SSL provider: It is strongly recommended that you urgently upgrade to this version. It was brought to our attention by a Debian developer[1] that code added in 3.2.0/2.4.0 have licensing terms that are incompatible with redistribution under the GPLv2, if used to link with GPLv2 licensed code. In these versions, Netatalk is linked with the offending code when using the Meson build system and enable the bundled SSL provider. When the bundled SSL provider is disabled, or when using Autotools, this does not become an issue. [1] https://github.com/Netatalk/netatalk/issues/1185 Please note that the above does not constitute legal advice. We are laypersons advised by other laypersons... Anyhow, the offending code (5 files, a total of ~1000 lines) have been removed from distribution altogether. Instead, OpenSSL or LibreSSL is now required (again) when building the bundled SSL provider. As a side note, this does not constitute a complete reversion to the previous state: We still have WolfSSL as either a bundled or system-provided library that supplies the actual DHCAST128 implementation. OpenSSL/LibreSSL only provides the CAST algorithm itself, so the DHX UAM should be fully functional. We are currently looking into Nettle as a holistic crypto provider, potentially replacing both libcrypto (OpenSSL) and libgcrypt for all of Netatalk's encryption needs. So a future feature release may introduce a dependency on libnettle, if it all works out. Just as a heads-up... On behalf of the Netatalk Team, Daniel |
From: Daniel M. <da...@mi...> - 2024-06-29 13:57:56
|
Minor feature Netatalk versions 3.2.1 and 2.4.1 has been tagged and released. https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-1 https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-1 Security release 3.1.19 is also available. It was a busy day today... https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-1-19 What they have in common is a patch that addresses CVE-2024-38439, CVE-2024-38440, and CVE-2024-38441. The former two releases contain a range of bugfixes and improvements to the Meson build system, among other things. Most notably, 3.2.1 in particular has gotten a complete revamp of the naming and type of Meson options. While it's not normally advisable to make such a breaking change to a 0.0.1 bump, following the feedback from Hauke and others, we realized that it was a complete mess in 3.2.0. We think adopting Meson will be much less painful with this change. For all of you who already build locally or packaged Netatalk 3.2.0 with the original slate of Meson options, I created a table that breaks down exactly which options were renamed. The table is embedded in the 3.2.1 release notes, so please have a look! Please share any feedback or bugs that you run in to. On behalf of the Netatalk development team, Daniel |
From: Daniel M. <da...@mi...> - 2024-06-25 11:37:30
|
Hi all! Netatalk ships with a range of init scripts (distrib/iniscripts/). Among those are "rc.redhat" and "rc.suse". The Red Hat script is for Upstart, while the SuSE one is classic SysV. However, both of these moved on to systemd nearly a decade ago: Red Hat in 2014, and SuSE in 2015 according to my research. Additionally, neither of these distros have even an optional package anymore for restoring the traditional init system in their latest releases. As a result, we weren't even able to test them in the latest release cycle. Would anyone here be terribly inconvenienced if we removed these two in the next feature release for 3.x and 2.x? As a side note, we ship an OpenRC init script as a cross-platform alternative to systemd. Additionally, 3.x provides platform specific init scripts for Debian, FreeBSD, NetBSD, OpenBSD, macOS, and Solaris. Cheers! Daniel |
From: Daniel M. <da...@mi...> - 2024-06-23 06:32:44
|
Version 2.4.0 of Netatalk is now available. Find the full release notes and tarballs at https://github.com/Netatalk/netatalk/releases/tag/netatalk-2-4-0 The main changes in this version are mostly the same as in 3.2.0: - Meson build system - Bundled WolfSSL as crypto provider for DHX/RandNum - LDAP API bump; OpenLDAP 2.3 or later required Following Hauke's feedback to the 3.2.0 release, we reworked the Meson options and gave them more consistent namings+types. The Meson options are now one of two types: -Dwith-* of boolean true|false type, to turn a feature on or off -Dwith-*-path of string type, to point to some dependency The same Meson options rework will be part of an upcoming 3.x release. The release notes and INSTALL.md have more details. You can also run `meson configure' in the source tree's root to get a dynamic summary of all available options. We are excited about this new release, as it represents a major future proofing of Netatalk 2.x, keeping the lights on for AppleTalk networking in the 21st century. As a side note, v6.9 of the Linux kernel was released last month, and includes a fix for a long-standing AppleTalk broadcast bug. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=2e82a58d6c0797092eabe7ba66a532c11548047f Please share your feedback here or in the GitHub issue tracker! On behalf of the Netatalk team, Daniel |
From: Daniel M. <da...@mi...> - 2024-06-08 09:15:33
|
On Wednesday, June 5th, 2024 at 3:16 AM, Hauke Fath (SPG) <hf...@sp...> wrote: > > > On 2024-06-04 18:29, Hauke Fath (SPG) wrote: > > > o how can I disable ldap support for the build? Not setting the ldap > > path doesn't do it. > > > > o on NetBSD, I get Options: Quota support : NO, but User defined options > > enable-quota : enabled -- which one will it be? > > > > o despite -Dwith-bdb pointing to db5, the build fails to find it, thinks > > it found db4, and breaks. I couldn't quite find in meson-log.txt where > > this goes wrong. > > > > If it helps, I can share the build log. > > > ftp://ftp.causeuse.org/pub/pkgsrc/netatalk32.mesonlog.gz > > > Cheerio, > Hauke > > -- > The ASCII Ribbon Campaign Hauke Fath > () No HTML/RTF in email Institut für Nachrichtentechnik > /\ No Word docs in email TU Darmstadt > Respect for open standards Ruf +49-6151-16-21344 Hauke, Where are db4 and db5 headers installed on your NetBSD system? On my 9.4 system, I have the headers under /usr/pkg/include/db4 and /usr/pkg/include/db5 and the Netatalk meson build system picks up on the former. For your reference, when testing on NetBSD in our CI pipeline, we are using these parameters. meson setup build \ -Dpkg_config_path=/usr/pkg/lib/pkgconfig \ -Dwith-dtrace=false \ -Dwith-init-style=netbsd See: https://netatalk.io/3.2/htmldocs/compile#build-netbsd Regarding the two other build system issues: The inability to disable LDAP is definitely a bug and will be fixed in the next release. And with quota, if you look further up your meson log, there is this section: """ Library rpcsvc found: YES Library quota found: YES Run-time dependency libtirpc found: NO (tried pkgconfig and cmake) Has header "rpc/rpc.h" : YES (cached) Has header "rpc/pmap_prot.h" : YES Has header "rpcsvc/rquota.h" : YES (cached) Has header "rpc/rpc.h" : YES (cached) Checking for function "main" with dependency -lrpcsvc: NO meson.build:913: WARNING: Quota support requested but required libraries not found """ The list of "User defined options" in the setup summary just does exactly that: Lists up options that the user defined. It doesn't say whether the option was successfully enabled or not... One potential improvement here would be to fail the meson setup process if a user defined option leads to a failed dependency check. Thoughts? Daniel |
From: Daniel M. <da...@mi...> - 2024-06-07 03:35:12
|
2024年6月5日 (水) 01:29, Hauke Fath (SPG) <[hf...@sp...](mailto:2024年6月5日 (水) 01:29, Hauke Fath (SPG) <<a href=)> 送信: > On 2024-06-01 16:08, Daniel Markstedt wrote: >> On behalf of the Netatalk team, I'm proud to present version 3.2.0 of >> Netatalk. This marks just over 10 years since the last feature >> release of the mainline branch. We appreciate you all who use >> Netatalk and make up this community! > Hi Daniel, > > many thanks for your work, as always. > >> As has been shared on this list in previous months, there are two >> major changes in this release: >> >> - The Meson build system > has a few teething issues still. > > I think the naming of options could use a makeover: > > o with-ldap, with-gssapi, with-bdb really should be renamed with-*-path, > since that is what they take > > o there is a confusing mix of enable-* vs. with-* options, as well as > enable-* vs. disable-* > > o same for true|false vs. enabled|disabled > > Further issues: > > o how can I disable ldap support for the build? Not setting the ldap > path doesn't do it. > > o on NetBSD, I get Options: Quota support : NO, but User defined options > enable-quota : enabled -- which one will it be? > > o despite -Dwith-bdb pointing to db5, the build fails to find it, thinks > it found db4, and breaks. I couldn't quite find in meson-log.txt where > this goes wrong. > > If it helps, I can share the build log. > > Since you dropped the autoconf bootstrap files, I will probably wait > till the above is sorted before updating the net/netatalk3 package. > > Cheerio, > Hauke > > -- > The ASCII Ribbon Campaign Hauke Fath > () No HTML/RTF in email Institut für Nachrichtentechnik > /\ No Word docs in email TU Darmstadt > Respect for open standards Ruf +49-6151-16-21344 Hauke, Thank you for the feedback, as always! I agree with your assessment of the mess of option namings and parameters. The goal for this the initial revision of the Meson build system was a 1:1 parity between the Autotools and Meson option names, to make the transition self-explanatory. The plan is to revisit and clean up all the options at the same time as Autotools is removed, in a future feature release. (And at the same time align 2.x and 3.x) The other three issues are something I want to look into for 3.2.1. Would you be able to create a GitHub ticket for each of them? Best regards, Daniel |
From: Hauke F. (SPG) <hf...@sp...> - 2024-06-04 18:16:26
|
On 2024-06-04 18:29, Hauke Fath (SPG) wrote: > o how can I disable ldap support for the build? Not setting the ldap > path doesn't do it. > > o on NetBSD, I get Options: Quota support : NO, but User defined options > enable-quota : enabled -- which one will it be? > > o despite -Dwith-bdb pointing to db5, the build fails to find it, thinks > it found db4, and breaks. I couldn't quite find in meson-log.txt where > this goes wrong. > > If it helps, I can share the build log. <ftp://ftp.causeuse.org/pub/pkgsrc/netatalk32.mesonlog.gz> Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344 |
From: Hauke F. (SPG) <hf...@sp...> - 2024-06-04 16:47:55
|
On 2024-06-01 16:08, Daniel Markstedt wrote: > On behalf of the Netatalk team, I'm proud to present version 3.2.0 of > Netatalk. This marks just over 10 years since the last feature > release of the mainline branch. We appreciate you all who use > Netatalk and make up this community! Hi Daniel, many thanks for your work, as always. > As has been shared on this list in previous months, there are two > major changes in this release: > > - The Meson build system has a few teething issues still. I think the naming of options could use a makeover: o with-ldap, with-gssapi, with-bdb really should be renamed with-*-path, since that is what they take o there is a confusing mix of enable-* vs. with-* options, as well as enable-* vs. disable-* o same for true|false vs. enabled|disabled Further issues: o how can I disable ldap support for the build? Not setting the ldap path doesn't do it. o on NetBSD, I get Options: Quota support : NO, but User defined options enable-quota : enabled -- which one will it be? o despite -Dwith-bdb pointing to db5, the build fails to find it, thinks it found db4, and breaks. I couldn't quite find in meson-log.txt where this goes wrong. If it helps, I can share the build log. Since you dropped the autoconf bootstrap files, I will probably wait till the above is sorted before updating the net/netatalk3 package. Cheerio, Hauke -- The ASCII Ribbon Campaign Hauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-21344 |
From: Daniel M. <da...@mi...> - 2024-06-01 14:09:09
|
On behalf of the Netatalk team, I'm proud to present version 3.2.0 of Netatalk. This marks just over 10 years since the last feature release of the mainline branch. We appreciate you all who use Netatalk and make up this community! This release contains a long list of bugfixes, code quality improvements, and new features. Some of the code changes go pretty deep, so consider this an "early adopters" release. Tread carefully when upgrading a production system, and make sure your backups are up to date. Please find the full release notes and download links on GitHub: https://github.com/Netatalk/netatalk/releases/tag/netatalk-3-2-0 I also want to call out this new appendix in the html manual, which contains steps how to build from source for a large number of OSes: https://netatalk.io/stable/htmldocs/compile As has been shared on this list in previous months, there are two major changes in this release: - The Meson build system - Bundled WolfSSL As a direct result, of the above we no longer distribute pre-bootstrapped tarballs. The Autotools scripts and macros still exist and are fully functional. We commit to maintain Autotools for the lifetime of the 3.2 release series. However, it may be removed in a future feature release. The bulk of the WolfSSL code is licensed under the GPLv2, same as Netatalk proper. However, there are five source files under the original OpenSSL license, which may be a consideration for downstream packaging. While I'm mindful that some of these changes can be disruptive to your established workflows, and come with a learning curve, I'm genuinely excited about all the neat stuff in this release. I'm looking forward to hearing your feedback! Sincerely, Daniel |
From: Daniel M. <da...@mi...> - 2024-05-29 12:55:06
|
Hi Chris and everyone else who responded to this last year! In the end, we decided to keep Quota functionality intact in the netatalk 3.2 release cycle. Thanks to feedback from you and others, we got valuable context to where file system quotas can still be a useful feature for system administrators. We are in the final stretch to get 3.2.0 out the door now and excited about sharing it with you all shortly! Sincerely, Daniel On Friday, September 22nd, 2023 at 9:38 PM, Chris Devers <cd...@ed...> wrote: > I’m not sure if you’re looking for responses here, or in Github, so I’ll paste here what I just submitted to the Github discussion: > > This would have been a big problem for us a couple years ago. > > At my employer, we make heavy use of the quota feature for shared storage solutions, where different user groups get different space allocations. If quota support wasn’t available for AFP mounts, then this would have led to a lot of unexpected behavior & tech support calls with convoluted workarounds, because the quota limits would still be enforced at the server’s filesystem layer, but anyone using AFP would falsely be led to believe that each of their mounts has access to the full capacity of the overall system. We’d basically have to tell AFP users to ignore what Finder is telling them, and to instead look in other interfaces to understand their space allocation & availability information. > > For better or worse, the proposed change won’t matter to us nowadays …but that’s because we deprecated & removed Netatalk/AFP from our product, so our customers aren't using it anymore. When Apple started downplaying AFP support in modern Mac versions, our customers started switching to alternatives, so by the time we removed Netatalk, few if any of our customers were still using AFP anyway. > > (If Samba were to drop quota support, that would be a bigger headache for us. But that's a discussion for elsewhere.) > > There may well be other shared-storage products out there that are still making similar use of quotas, and might be caught out by this change. It certainly seems worth putting in something more than a dot-dot-patch release where people would normally only expect minor bug fixes, not the removal of a once-significant feature. Hopefully, any affected users/companies see this discussion before the September 25th deadline (three days from now) and can weigh in if this is going to be a problem for them. > > I certainly understand the desire to pay down technical debt, and phase out support for features that aren't widely used anymore, in order to make the slimmed-down software easier to support & extend. Hopefully it's true that the population of people using quotas with Netatalk is small enough now that this is the right course of action. Good luck! > > -- > Chris Devers > EditShare |
From: Daniel M. <da...@mi...> - 2024-04-20 13:45:26
|
I spent some time this week touching up the webmin modules for netatalk 3.x and 2.x. For the former, I made it fully compliant with all options that 3.1.18 provides, so I took the liberty of tagging a v1.0 first stable release. I've fixed all the bugs that I've found so far, so I think it's in good shape now. https://github.com/Netatalk/netatalk-webmin/releases/tag/netatalk3-1.0 Additionally, a minor bugfix/improvement release for the 2.x module can be found here: https://github.com/Netatalk/netatalk-webmin/releases/tag/netatalk2-1.3 I've seen a recent uptick in interest (download numbers) for the 3.x module which got me motivated to work on it. Enjoy! Daniel |
From: Daniel M. <da...@mi...> - 2024-04-09 00:18:15
|
Thanks for sharing your thoughts, Gregory. Every technical decision has tradeoffs. Meson is not perfect by any means. But it's easier to work with for us active contributors, and is very fast. Back when this project needed to support all of the big proprietary Unixi, I agree Autotools was the right tool for the job. Now the only proprietary OSes we actively support are Solaris 11 and macOS. Cheers, Daniel On Tuesday, April 9th, 2024 at 2:57 AM, Gregory Carter <gjc...@gm...> wrote: > Yeah maybe autohell was a thing back in the 1990's when there was BSD/AT&T Unixes floating around. > > Today it has largely consolidated on Linux and of course NetBSD/FreeBSD, not so much a autohell anymore as "purgatory light". > > Which being a Devils advocate here Meson isn't immune to build issues, Mavon isn't immune to build issues either. > > I used them all and I think at this stage in the game given the limited interest that this project has, I COULD make the argument that we just pick whatever build system or tool chain we can get based on who is actually willing to work on the project. > > It is voluntary afterall. > > Welcome to Pragmatic Monday. > > On Fri, Mar 1, 2024 at 10:25 AM Hauke Fath (SPG) <hf...@sp...> wrote: > > > On 2024-02-27 08:32, Daniel Markstedt wrote: > > > A question for you all: How would it affect you if Netatalk moved to > > > the Meson build system > > > > The primary benefits that we over traditional GNU autotools are: > > > > [...] > > > > > The main drawback is of course the disruption to package maintainers > > > or sysadmins who like to roll their own binaries. > > > > For those of us who have been around the block a few times, autohell is > > a known quantity (never thought I'd say that, I was quite miffed when > > Netatalk got autotooled...). > > > > But you are the main maintainer at this point (kudos!), pick what works > > for you. > > > > Cheerio, > > Hauke > > > > -- > > The ASCII Ribbon Campaign Hauke Fath > > () No HTML/RTF in email Institut für Nachrichtentechnik > > /\ No Word docs in email TU Darmstadt > > Respect for open standards Ruf +49-6151-16-21344 > > > > > > _______________________________________________ > > Netatalk-admins mailing list > > Net...@li... > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins |
From: Gregory C. <gjc...@gm...> - 2024-04-08 17:57:29
|
Yeah maybe autohell was a thing back in the 1990's when there was BSD/AT&T Unixes floating around. Today it has largely consolidated on Linux and of course NetBSD/FreeBSD, not so much a autohell anymore as "purgatory light". Which being a Devils advocate here Meson isn't immune to build issues, Mavon isn't immune to build issues either. I used them all and I think at this stage in the game given the limited interest that this project has, I COULD make the argument that we just pick whatever build system or tool chain we can get based on who is actually willing to work on the project. It is voluntary afterall. Welcome to Pragmatic Monday. On Fri, Mar 1, 2024 at 10:25 AM Hauke Fath (SPG) <hf...@sp...> wrote: > On 2024-02-27 08:32, Daniel Markstedt wrote: > > A question for you all: How would it affect you if Netatalk moved to > > the Meson build system > > > The primary benefits that we over traditional GNU autotools are: > > [...] > > > The main drawback is of course the disruption to package maintainers > > or sysadmins who like to roll their own binaries. > > For those of us who have been around the block a few times, autohell is > a known quantity (never thought I'd say that, I was quite miffed when > Netatalk got autotooled...). > > But you are the main maintainer at this point (kudos!), pick what works > for you. > > Cheerio, > Hauke > > -- > The ASCII Ribbon Campaign Hauke Fath > () No HTML/RTF in email Institut für Nachrichtentechnik > /\ No Word docs in email TU Darmstadt > Respect for open standards Ruf +49-6151-16-21344 > > > _______________________________________________ > Netatalk-admins mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netatalk-admins > |
From: Ralph B. <sl...@sa...> - 2024-04-08 14:55:15
|
On 4/8/24 14:16, Daniel Markstedt wrote: > We are looking forward to getting your feedback! great work!! Cheers! -slow |