You can subscribe to this list here.
2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
(116) |
Sep
(69) |
Oct
(48) |
Nov
(40) |
Dec
(36) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2001 |
Jan
(39) |
Feb
(58) |
Mar
(199) |
Apr
(130) |
May
(128) |
Jun
(231) |
Jul
(120) |
Aug
(236) |
Sep
(198) |
Oct
(408) |
Nov
(596) |
Dec
(436) |
2002 |
Jan
(374) |
Feb
(405) |
Mar
(341) |
Apr
(228) |
May
(293) |
Jun
(119) |
Jul
(184) |
Aug
(173) |
Sep
(177) |
Oct
(168) |
Nov
(156) |
Dec
(154) |
2003 |
Jan
(167) |
Feb
(200) |
Mar
(103) |
Apr
(85) |
May
(63) |
Jun
(50) |
Jul
(52) |
Aug
(51) |
Sep
(110) |
Oct
(68) |
Nov
(101) |
Dec
(46) |
2004 |
Jan
(91) |
Feb
(61) |
Mar
(69) |
Apr
(119) |
May
(61) |
Jun
(64) |
Jul
(53) |
Aug
(122) |
Sep
(45) |
Oct
(33) |
Nov
(81) |
Dec
(19) |
2005 |
Jan
(27) |
Feb
(28) |
Mar
(11) |
Apr
(20) |
May
(31) |
Jun
(20) |
Jul
(19) |
Aug
(28) |
Sep
(21) |
Oct
(16) |
Nov
(6) |
Dec
(1) |
2006 |
Jan
(10) |
Feb
(13) |
Mar
(19) |
Apr
(3) |
May
(9) |
Jun
(20) |
Jul
(13) |
Aug
(22) |
Sep
(35) |
Oct
(25) |
Nov
(4) |
Dec
|
2007 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(9) |
Sep
|
Oct
(10) |
Nov
|
Dec
(1) |
2008 |
Jan
(1) |
Feb
(7) |
Mar
(44) |
Apr
(30) |
May
(30) |
Jun
(12) |
Jul
(4) |
Aug
(18) |
Sep
(3) |
Oct
(3) |
Nov
(13) |
Dec
(21) |
2009 |
Jan
(58) |
Feb
(50) |
Mar
(56) |
Apr
(82) |
May
(98) |
Jun
(100) |
Jul
(71) |
Aug
(41) |
Sep
(66) |
Oct
(67) |
Nov
(169) |
Dec
(113) |
2010 |
Jan
(162) |
Feb
(92) |
Mar
(45) |
Apr
(107) |
May
(45) |
Jun
(76) |
Jul
(12) |
Aug
(7) |
Sep
(2) |
Oct
(9) |
Nov
(19) |
Dec
(3) |
2011 |
Jan
(59) |
Feb
(4) |
Mar
(33) |
Apr
(7) |
May
(6) |
Jun
(4) |
Jul
(51) |
Aug
(18) |
Sep
(25) |
Oct
(9) |
Nov
(17) |
Dec
(33) |
2012 |
Jan
(39) |
Feb
(45) |
Mar
(147) |
Apr
(19) |
May
(41) |
Jun
(26) |
Jul
(7) |
Aug
(52) |
Sep
(20) |
Oct
(22) |
Nov
(13) |
Dec
(11) |
2013 |
Jan
(28) |
Feb
(20) |
Mar
(29) |
Apr
(6) |
May
(16) |
Jun
(9) |
Jul
(24) |
Aug
(9) |
Sep
(1) |
Oct
(18) |
Nov
(4) |
Dec
(5) |
2014 |
Jan
(26) |
Feb
(5) |
Mar
(4) |
Apr
|
May
(10) |
Jun
(14) |
Jul
(4) |
Aug
(19) |
Sep
(9) |
Oct
(1) |
Nov
(6) |
Dec
(1) |
2015 |
Jan
(7) |
Feb
|
Mar
(3) |
Apr
(9) |
May
|
Jun
|
Jul
(5) |
Aug
(1) |
Sep
|
Oct
(24) |
Nov
(5) |
Dec
(9) |
2016 |
Jan
|
Feb
(11) |
Mar
(1) |
Apr
(6) |
May
(27) |
Jun
(50) |
Jul
(12) |
Aug
(5) |
Sep
(3) |
Oct
|
Nov
(12) |
Dec
(22) |
2017 |
Jan
(12) |
Feb
(9) |
Mar
(8) |
Apr
(2) |
May
(6) |
Jun
(4) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(2) |
2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(3) |
2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2020 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2022 |
Jan
(5) |
Feb
|
Mar
(8) |
Apr
(1) |
May
|
Jun
|
Jul
(4) |
Aug
(1) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
2023 |
Jan
(26) |
Feb
(33) |
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(3) |
Nov
(4) |
Dec
(5) |
2024 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Daniel M. <da...@mi...> - 2024-02-27 07:33:03
|
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: - It's fast! - Used by well-established open source projects such as qemu, mesa, freedesktop.org (eg dbus), Gnome, glib - The meson.build files have a transparent logic and are easy to update - The dependency search function works really well cross-platform so less user intervention with configure options is required The main drawback is of course the disruption to package maintainers or sysadmins who like to roll their own binaries. So before making the final decision, I want to hear the Voice of the Customer, as it were. :) Here is the ticket in question: https://github.com/Netatalk/netatalk/issues/707 Cheers, Daniel |
From: Daniel M. <da...@mi...> - 2023-12-19 01:54:57
|
Dear Netatalk community, I'm here again to present another deprecation proposal, to understand how this would impact your use cases. - Remove the Randnum UAM, while moving to WolfSSL as the backend for the DHX UAM. The full discussion can be found in this ticket: https://github.com/Netatalk/netatalk/issues/358 TL;DR; OpenSSL 3.0 dropped support for DHCAST128 which backs the DHX UAM. The DHX UAM code still builds, but throws errors when a Classic Mac OS client tries to authenticate. More and more OS distributions are migrating to OpenSSL 3.0, so this is getting to be a bigger and bigger obstacle for getting started with Netatalk. The current plan is to use WolfSSL as a drop-in solution. WolfSSL has an OpenSSL compatibility layer which covers DHCAST123. However it does not implement the symbols that Randnum needs. Decoupling DHX and Randnum turned out to be a huge effort, so we are proposing to remove Randnum altogether from Netatalk 3.x. Randnum will continue to be supported in the Netatalk 2.x branch (probably by sacrificing DHX.) There is an unofficial extension for DHX auth on Mac OS 9. And you always have the Clear Text UAM option if you absolutely need very old Mac OS clients to connect to your Netatalk 3.x server. I'm very curious to hear your thoughts on this situation! Best regards, Daniel |
From: David R. <fra...@gm...> - 2023-12-15 20:47:53
|
On Dec 15, 2023, at 4:58 AM, Hauke Fath <hf...@sp...> wrote: > > On Fri, 15 Dec 2023 09:00:33 +0000, Daniel Markstedt wrote: >> When you log to a file (the "log file" option), netatalk is hard >> coded to output a time stamp in this format: Dec 08 15:59:35.402141 >> >> However, it has recently been reported by a user that the microsecond >> granularity is causing incompatibility with a particular log >> management solution that they are using. > > Well, my knee-jerk reaction: Netatalk shouldn't have to adapt to an > inflexible, effectively borken log parser. And, further, changing the log format runs the near-certain risk of breaking many other (presumably also poorly-written and inflexible) things already parsing netatalk logs; ideally, this would be solved with a log format directive that defaults to the current format, which is how many other daemons handle this. It's a little surprising to me that it's hardcoded, to be honest. I could have sworn there was a format directive, but I must have dreamed it. No, most of us probably don't *need* microsecond precision (though it seldom hurts), but beware making sudden changes in long-unchanged outputs, which are de facto standards whether we'd like them to be or not. >> Off the top of my head, I can think of one reason for microsecond >> accuracy: Fine-grained performance profiling. > > With faster machines, more things happen within a second. When the > events reported happened at distinctly different times, it makes a lot > of sense to provide the exact time stamp. Basically this. I've had situations where sub-millisecond precision has made the difference in diagnosing a race condition. - Dave |
From: Hauke F. <hf...@sp...> - 2023-12-15 10:23:19
|
On Fri, 15 Dec 2023 09:00:33 +0000, Daniel Markstedt wrote: > When you log to a file (the "log file" option), netatalk is hard > coded to output a time stamp in this format: Dec 08 15:59:35.402141 > > However, it has recently been reported by a user that the microsecond > granularity is causing incompatibility with a particular log > management solution that they are using. Well, my knee-jerk reaction: Netatalk shouldn't have to adapt to an inflexible, effectively borken log parser. > In addition, I think the microsecond logging clutters the logs. Run the log through sed(1) if you want the microseconds cut out? > It's worth noting that Netatalk logs with second accuracy to syslog > by default on all systems I've looked at (probably controlled by a > system level log daemon?) That's syslogd (on my NetBSD machine, at least ;) providing the time stamps. The bug reporter is talking about having netatalk log to a *file*, in which case it provides its own timestamps. > Off the top of my head, I can think of one reason for microsecond > accuracy: Fine-grained performance profiling. With faster machines, more things happen within a second. When the events reported happened at distinctly different times, it makes a lot of sense to provide the exact time stamp. My 0.02 EUR, 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. <hauke@Espresso.Rhein-Neckar.DE> - 2023-12-15 09:41:29
|
On Fri, 15 Dec 2023 09:00:33 +0000, Daniel Markstedt wrote: > When you log to a file (the "log file" option), netatalk is hard > coded to output a time stamp in this format: Dec 08 15:59:35.402141 > > However, it has recently been reported by a user that the microsecond > granularity is causing incompatibility with a particular log > management solution that they are using. Well, my knee-jerk reaction: Netatalk shouldn't have to adapt to an inflexible, effectively borken log parser. > In addition, I think the microsecond logging clutters the logs. Run the log through sed(1) if you want the microseconds cut out? > It's worth noting that Netatalk logs with second accuracy to syslog > by default on all systems I've looked at (probably controlled by a > system level log daemon?) That's syslogd (on my NetBSD machine, at least ;) providing the time stamps. The bug reporter is talking about having netatalk log to a *file*, in which case it provides its own timestamps. > Off the top of my head, I can think of one reason for microsecond > accuracy: Fine-grained performance profiling. With faster machines, more things happen within a second. When the events reported happened at distinctly different times, it makes a lot of sense to provide the exact time stamp. My 0.02 EUR, Hauke -- Hauke Fath <hauke@Espresso.Rhein-Neckar.DE> Linnéweg 7 64342 Seeheim-Jugenheim Germany |
From: Daniel M. <da...@mi...> - 2023-12-15 09:01:01
|
Dear Netatalk community: Are you all relying on microsecond accuracy in netatalk logs? When you log to a file (the "log file" option), netatalk is hard coded to output a time stamp in this format: Dec 08 15:59:35.402141 However, it has recently been reported by a user that the microsecond granularity is causing incompatibility with a particular log management solution that they are using. In addition, I think the microsecond logging clutters the logs. It's worth noting that Netatalk logs with second accuracy to syslog by default on all systems I've looked at (probably controlled by a system level log daemon?) Off the top of my head, I can think of one reason for microsecond accuracy: Fine-grained performance profiling. This is the ticket in question: https://github.com/Netatalk/netatalk/issues/580 If noone objects to changing to second accuracy in log time stamps, I will make the change in one week's time (Friday 12/22). Thank you! Daniel |
From: Jeff H. <jef...@gm...> - 2023-11-19 00:08:10
|
"huge boon" Agree! I use afp between my linux server and my 2019 MacBook Pro running macOS Venture 13.5.2. It seems to be superior to smb, which one other device uses. I don't know if my Linux-macOS context uses the feature you describe but I would be very unhappy if I had to switch to smb for all of my devices. For a 6 month period or so, when I couldn't get this product compiled on the linux server, I had to use smb everywhere and I was none too happy. On Sat, Nov 18, 2023 at 5:46 PM Daniel Markstedt <da...@mi...> wrote: > Chris, > > Yes, very helpful. Thank you. I am convinced to keep the FCE feature in > the upcoming 3.2 release cycle. > > I sincerely hope Apple doesn't kill off their AFP client in macOS any time > soon. It's been a huge boon to be able to seamlessly do file sharing from > very old Macs or even Apple IIs with the latest macOS clients using > netatalk as a bridge software. > > As a side note, we actually got netatalk working fine on macOS hosts again > earlier this year, serving AFP volumes on APFS file systems. Apple of > course did away with their atalk kernel module for OSX 10+ years ago, so > it's TCP/IP-only. > > Cheers, > Daniel > On Wednesday, November 15th, 2023 at 2:15 PM, Chris Devers < > cd...@ed...> wrote: > > On Tue, Nov 14, 2023 at 11:39 PM Daniel Markstedt <da...@mi...> > wrote: > >> For the example of the video production software: >> Do you know for a fact that this software was sensitive to the Netatalk >> FCE events specifically? >> Or do you assume that it was based on the overall health of the system? >> > > I’m a little reluctant to get *too* specific on a public mailing list, but > yeah, the mainstream professional media software that people use for > producing TV, film, advertising, streaming, etc media all frequently seem > to use such capabilities. > > My sense is that when the applications detect that they’re writing to > storage, they have mechanisms for determining whether the storage is local > or remote, whether it supports various semantic operations, whether it > supports things like normalized Unicode encoding for filenames, etc. And > among the capabilities that get checked would be for things like file > locking and filesystem change events, and depending on whether or not such > functionality is determined to be available, certain features get enabled > or disabled, as appropriate. > >> I guess what I’m trying to get at is whether Netatalk’s FCE is an >> “industry standard” as it were, or if software had to be coded specifically >> to be Netatalk aware, i.e. be modified for an enterprise rollout that >> included Netatalk. >> > > I haven't gone spelunking through the source code or the network packet > traces, etc, but my sense is that the behavior tends to be as above: > there’s a check for whether the storage is local or remote (more things, > like Spotlight & Trash support, get turned on if the volume is “local”), > and if the storage is “remote”, then the applications may tend to proceed > not based on whether the volume is AFP/SMB/NFS/etc, but based on whether > particular options, like filesystem change events, appear to be working or > not. > > I wouldn’t want to force enterprise users to stay an old Netatalk version, >> and miss out on security and stability improvements. > > > Yeah, this is always the tension: upgrade or patch one thing, and > everything else may need to update, too; hold back on updating one thing, > and everything else can also be held back. Either way makes life harder for > sysadmins. > > If someone is serving a fleet of older Macs and can’t realistically >> migrate to Samba, I want Netatalk3 to remain a viable choice. >> > > I think Apple are the primary drivers here, as AFP already can't be served > from new Macs booting from APFS volumes, and the company has been signaling > that macOS is likely to drop AFP client support in the future. Anyone still > using AFP “professionally” has to be aware of this, and must be making > plans to migrate to other options, if they haven't already done so. > > With video production, it can be the case that, for example, somebody buys > a specialized piece of equipment, like a video ingest box, and maybe that > piece of equipment is very expensive. It's sometimes the case that these > products are sold but don’t really have upgradeable software or firmware, > so they’re originally designed to work with particular Windows or Mac OS X > / macOS versions, and they don’t necessarily work with later versions. > Products like this can put people in a bind, because they have a > workstation that’s older, but still doing useful work, and the replacement > cost might be prohibitive, so they keep it on an older operating system > version, and in turn might also have to hold back upgrades of other systems > — like the AFP file server — because then they’re going down the rabbit > hole of having to come up with a new matrix of compatible versions of > everything they need to manage. Also, periods of downtime due to upgrades & > testing can lead to lost revenue, which can further lead to a reluctance to > make any changes if the status quo is “stable enough”, “secure enough”, > etc. > > My sense is that anyone in a situation like this realizes that it's not a > great scenario, and they’re eager to migrate to something better — like > Samba, if possible, but other options exist as well. But the transition > process can be disruptive, so there’s an instinct to stick with tools (such > as AFP and its existing FCE support, even if it’s imperfect) that are known > to be “good enough, for now”. > > Helpful? > > > _______________________________________________ > Netatalk-devel mailing list > Net...@li... > https://lists.sourceforge.net/lists/listinfo/netatalk-devel > |
From: Daniel M. <da...@mi...> - 2023-11-18 23:46:13
|
Chris, Yes, very helpful. Thank you. I am convinced to keep the FCE feature in the upcoming 3.2 release cycle. I sincerely hope Apple doesn't kill off their AFP client in macOS any time soon. It's been a huge boon to be able to seamlessly do file sharing from very old Macs or even Apple IIs with the latest macOS clients using netatalk as a bridge software. As a side note, we actually got netatalk working fine on macOS hosts again earlier this year, serving AFP volumes on APFS file systems. Apple of course did away with their atalk kernel module for OSX 10+ years ago, so it's TCP/IP-only. Cheers, Daniel On Wednesday, November 15th, 2023 at 2:15 PM, Chris Devers <cd...@ed...> wrote: > On Tue, Nov 14, 2023 at 11:39 PM Daniel Markstedt <da...@mi...> wrote: > >> For the example of the video production software: >> Do you know for a fact that this software was sensitive to the Netatalk FCE events specifically? >> Or do you assume that it was based on the overall health of the system? > > I’m a little reluctant to get *too* specific on a public mailing list, but yeah, the mainstream professional media software that people use for producing TV, film, advertising, streaming, etc media all frequently seem to use such capabilities. > > My sense is that when the applications detect that they’re writing to storage, they have mechanisms for determining whether the storage is local or remote, whether it supports various semantic operations, whether it supports things like normalized Unicode encoding for filenames, etc. And among the capabilities that get checked would be for things like file locking and filesystem change events, and depending on whether or not such functionality is determined to be available, certain features get enabled or disabled, as appropriate. > >> I guess what I’m trying to get at is whether Netatalk’s FCE is an “industry standard” as it were, or if software had to be coded specifically to be Netatalk aware, i.e. be modified for an enterprise rollout that included Netatalk. > > I haven't gone spelunking through the source code or the network packet traces, etc, but my sense is that the behavior tends to be as above: there’s a check for whether the storage is local or remote (more things, like Spotlight & Trash support, get turned on if the volume is “local”), and if the storage is “remote”, then the applications may tend to proceed not based on whether the volume is AFP/SMB/NFS/etc, but based on whether particular options, like filesystem change events, appear to be working or not. > >> I wouldn’t want to force enterprise users to stay an old Netatalk version, and miss out on security and stability improvements. > > Yeah, this is always the tension: upgrade or patch one thing, and everything else may need to update, too; hold back on updating one thing, and everything else can also be held back. Either way makes life harder for sysadmins. > >> If someone is serving a fleet of older Macs and can’t realistically migrate to Samba, I want Netatalk3 to remain a viable choice. > > I think Apple are the primary drivers here, as AFP already can't be served from new Macs booting from APFS volumes, and the company has been signaling that macOS is likely to drop AFP client support in the future. Anyone still using AFP “professionally” has to be aware of this, and must be making plans to migrate to other options, if they haven't already done so. > > With video production, it can be the case that, for example, somebody buys a specialized piece of equipment, like a video ingest box, and maybe that piece of equipment is very expensive. It's sometimes the case that these products are sold but don’t really have upgradeable software or firmware, so they’re originally designed to work with particular Windows or Mac OS X / macOS versions, and they don’t necessarily work with later versions. Products like this can put people in a bind, because they have a workstation that’s older, but still doing useful work, and the replacement cost might be prohibitive, so they keep it on an older operating system version, and in turn might also have to hold back upgrades of other systems — like the AFP file server — because then they’re going down the rabbit hole of having to come up with a new matrix of compatible versions of everything they need to manage. Also, periods of downtime due to upgrades & testing can lead to lost revenue, which can further lead to a reluctance to make any changes if the status quo is “stable enough”, “secure enough”, etc. > > My sense is that anyone in a situation like this realizes that it's not a great scenario, and they’re eager to migrate to something better — like Samba, if possible, but other options exist as well. But the transition process can be disruptive, so there’s an instinct to stick with tools (such as AFP and its existing FCE support, even if it’s imperfect) that are known to be “good enough, for now”. > > Helpful? |
From: Daniel M. <da...@mi...> - 2023-11-15 04:39:34
|
Chris, Ah yes you’re right, I didn’t create a ticket (yet) for this one. The mailing list archive is a fine place for recording this conversation. :) Thanks again for leaning in with a concrete use case from your experience. This really helps me contextualize why these features exist in the first place. For the example of the video production software: Do you know for a fact that this software was sensitive to the Netatalk FCE events specifically? Or do you assume that it was based on the overall health of the system? I guess what I’m trying to get at is whether Netatalk’s FCE is an “industry standard” as it were, or if software had to be coded specifically to be Netatalk aware, i.e. be modified for an enterprise rollout that included Netatalk. I wouldn’t want to force enterprise users to stay an old Netatalk version, and miss out on security and stability improvements. If someone is serving a fleet of older Macs and can’t realistically migrate to Samba, I want Netatalk3 to remain a viable choice. Cheers! Daniel On Wed, Nov 15, 2023 at 6:27 AM, Chris Devers <[cd...@ed...](mailto:On Wed, Nov 15, 2023 at 6:27 AM, Chris Devers <<a href=)> wrote: > Hello, me again. I’ve commented on a couple of Github discussions recently, but I don’t see a Github link on this one, so I’m responding to the mailing list instead. > > On Sat, Nov 4, 2023 at 11:42 AM Daniel Markstedt <da...@mi...> wrote: > >> Would getting rid of FCE (Filesystem Change Events) have an averse impact on your netatalk deployments? > > I’m pretty sure this would have been a problem for us. > > My employer makes shared storage servers for video production workflows, and it's common for the mainstream video editing applications to make use of filesystem change notifications in various ways, e.g. “someone just added a new file”, “someone just updated a file”, “someone has a file open for writing”, etc. > > If this functionality weren’t available, then the behavior can degrade in various ways, depending on the applications in question and the workflows being used. Optimistically, the software could just end up, say, re-scanning the contents of the volume repeatedly, looking for changes that may or may not have occurred; this might hurt performance a bit, but perhaps not that badly, depending on the particulars. In other cases though, the software could end up doing “incorrect” things, like trying to regenerate an index database that is already being updated or has recently been updated, or (perhaps) ignoring the fact that another client already has a file open for writing. These are just examples; I imagine that there are lots of weird edge cases that could arise in particular scenarios. > > The “good” news, in our case, is that we deprecated AFP/Netatalk support a couple years ago, so removing the functionality at this point would have no impact on us anymore. > > It’s possible that other “enterprise” / “professional” users of Netatalk/AFP are still using this functionality, but as Apple themselves continue to phase out AFP support, this is mainly going to be relevant for people who are for various reasons running older Mac workstations — and if that’s the case, maybe they can & should also just run an older version of Netatalk, too. > > -- > Chris Devers |
From: Daniel M. <da...@mi...> - 2023-11-04 15:41:45
|
Dear Netatalk community, In the ongoing effort of streamlining the codebase, this suggestion might be the most controversial yet: Would getting rid of FCE (Filesystem Change Events) have an averse impact on your netatalk deployments? Do you know of anyone who relies on its API or logging for any kind of mission critical feature? For the uninitiated, FCE is an API that lets you build applications that react on changes to files on the shared volume. Docs here: https://netatalk.sourceforge.io/3.1/htmldocs/configuration.html#fce The argument for deprecation is twofold: For one, it's a fairly complex feature with 9 events and 8 dedicated afp.conf options: https://netatalk.sourceforge.io/3.1/htmldocs/afp.conf.5.html#fceconf And secondly, it's has long-outstanding bugs such as: https://github.com/Netatalk/netatalk/issues/122 I'd love to get your opinions on this! Cheers, Daniel |
From: Daniel M. <da...@mi...> - 2023-10-21 12:04:37
|
Dear Netatalk users, To continue with our mission to make Netatalk safer and more maintainable, I would like to propose removing "afprun" functionality from the next point release of Netatalk (3.2.0). Ticket for tracking: https://github.com/Netatalk/netatalk/issues/550 What this means, is that the following options will be removed: - preexec - root preexec - postexec - root postexec - preexec close - root preexec close - stat vol This code constitutes a major opportunity to run arbitrary shell commands (with root privileges) on the host, with all sorts of security implication. Do you have deployments of Netatalk that rely on the above? If so, we would love to know more about your use case! Thank you! Daniel |
From: Daniel M. <da...@mi...> - 2023-10-02 23:51:51
|
Hi Andres, Thanks for your suggestion. We have an option for CNID dircachesize in afp.conf already. Is this akin to what you are asking for? The documentation says: ==== dircachesize = number (G) Maximum possible entries in the directory cache. The cache stores directories and files. It is used to cache the full path to directories and CNIDs which considerably speeds up directory enumeration. Default size is 8192, maximum size is 131072. Given value is rounded up to nearest power of 2. Each entry takes about 100 bytes, which is not much, but remember that every afpd child process for every connected user has its cache. ==== See https://netatalk.sourceforge.io/3.1/htmldocs/afp.conf.5.html Also, "dbd" is what we call the CNID backend in question. We have some documentation in the manual: https://netatalk.sourceforge.io/3.1/htmldocs/configuration.html#CNID-backends Best, Daniel ------- Original Message ------- On Tuesday, October 3rd, 2023 at 7:23 AM, Andres Valloud <te...@sm...> wrote: > > > Hi, for dbd (did you mean bdb?), you might also consider adding a > db_param file with e.g. > > cachesize 131072 > > by default. > > Andres. > > On 10/2/23 2:23 PM, Daniel Markstedt wrote: > > > Dear Netatalk community, > > > > The next step in the effort to reduce the tech debt and improve the > > maintainability of Netatalk: > > Evaluating the utility of, and deprecating several little-used CNID > > backends. > > > > At the time of writing, Netatalk has accumulated no less than 5 CNID > > backends. > > They are: > > > > * cdb > > * dbd > > * last > > * mysql > > * tdb > > > > The dbd backend has been the default for over a decade. > > Is there anyone in the crowd here who actively use any of the other four > > today? > > We are considering deprecating all four, unless there is a concrete > > usecase that dbd cannot fulfill. > > > > See this github ticket for additional context and discussion: > > https://github.com/Netatalk/netatalk/issues/508 > > https://github.com/Netatalk/netatalk/issues/508 > > > > Thank you! > > > > Daniel > > > > _______________________________________________ > > Netatalk-admins mailing list > > Net...@li... > > https://lists.sourceforge.net/lists/listinfo/netatalk-admins |
From: Daniel M. <da...@mi...> - 2023-10-02 21:23:56
|
Dear Netatalk community, The next step in the effort to reduce the tech debt and improve the maintainability of Netatalk: Evaluating the utility of, and deprecating several little-used CNID backends. At the time of writing, Netatalk has accumulated no less than 5 CNID backends. They are: - cdb - dbd - last - mysql - tdb The dbd backend has been the default for over a decade. Is there anyone in the crowd here who actively use any of the other four today? We are considering deprecating all four, unless there is a concrete usecase that dbd cannot fulfill. See this github ticket for additional context and discussion: https://github.com/Netatalk/netatalk/issues/508 Thank you! Daniel |
From: Daniel M. <mar...@gm...> - 2023-04-03 19:27:21
|
Andy, The main development branch now contains a patch for CVE-2022-45188. It will be included in the next mainline release of Netatalk. Best, Daniel On Thu, Feb 9, 2023 at 10:43 PM Daniel Markstedt <mar...@gm...> wrote: > Hi Andy, > > Looking at the commit log for 3.0.14 I don't think there were explicit > fixes for either of those CVEs. > I think it's safe to say that both advisories are still outstanding. > > Best, > Daniel > > On Wed, Jan 11, 2023 at 7:02 AM Andrew Bauer <kni...@ou...> > wrote: > >> Hello - >> >> These CVE's were reported against the fedora netatalk 3.0.13 package: >> >> CVE-2022-45188 netatalk: heap-based buffer overflow resulting in code >> execution via a crafted .appl >> https://nvd.nist.gov/vuln/detail/CVE-2022-45188 >> >> CVE-2022-22995 netatalk: default configuration allows the arbitrary >> writing of files >> https://nvd.nist.gov/vuln/detail/cve-2022-22995 >> >> Have either of these been addressed in the recent 3.0.14 release? I do >> not see direct mention of these CVE's in the release notes on github. >> >> Thanks, >> Andy >> >> _______________________________________________ >> Netatalk-devel mailing list >> Net...@li... >> https://lists.sourceforge.net/lists/listinfo/netatalk-devel >> > |
From: Daniel M. <mar...@gm...> - 2023-03-27 23:02:06
|
Hi Ralph, Thanks for that. I made the scan setting more permissive (any user) but it turns out there is a limitation with Github as well. It won't pass tokens from the main repo to a job running on a forked repo. https://docs.github.com/en/actions/security-guides/encrypted-secrets#using-encrypted-secrets-in-a-workflow So I merged a small configuration change to main to only run Sonar scans on PRs originating from within the main repo. This way we at least squelch the false failed scans noise. BTW, I have a dozen PRs ready for your review. Nothing complex, but good to get your eyes on them. Thanks! Daniel On Mon, Mar 27, 2023 at 5:14 AM Ralph Boehme <sl...@sa...> wrote: > Hi Daniel, > > On 3/26/23 23:46, Daniel Markstedt wrote: > > I think it makes more sense to allow code scanning on all PRs. > > If you make me admin of the Sonar project I can try to figure out the > > permissions. > > I've added you to the owner group. > > Cheers! > -slow > > |
From: Ralph B. <sl...@sa...> - 2023-03-27 12:15:07
|
Hi Daniel, On 3/26/23 23:46, Daniel Markstedt wrote: > I think it makes more sense to allow code scanning on all PRs. > If you make me admin of the Sonar project I can try to figure out the > permissions. I've added you to the owner group. Cheers! -slow |
From: Daniel M. <mar...@gm...> - 2023-03-26 21:46:42
|
Hi Ralph, It turns out Sonar scanning is only permitted on PRs submitted by project members. If the branch originate from a fork, the scan will fail with: ERROR: Project not found. Please check the 'sonar.projectKey' and 'sonar.organization' properties, the 'SONAR_TOKEN' environment variable, or contact the project administrator I think it makes more sense to allow code scanning on all PRs. If you make me admin of the Sonar project I can try to figure out the permissions. Best, Daniel |
From: Ralph B. <sl...@sa...> - 2023-02-26 10:49:26
|
Hi! I've now renamed the branch from master to main. github suggested the following commands to adjust the local repo: git branch -m master main git fetch origin git branch -u origin/main main git remote set-head origin -a -slow -- Ralph Boehme, Samba Team https://samba.org/ SerNet Samba Team Lead https://sernet.de/en/team-samba |
From: Daniel M. <mar...@gm...> - 2023-02-26 07:16:08
|
....aaaand we have an initial report :) https://sonarcloud.io/summary/overall?id=Netatalk_netatalk BTW we may want to turn off the code coverage quality gate. Getting 80%+ UT coverage seems like a tall order for this codebase. On Sat, Feb 25, 2023 at 3:09 PM Daniel Markstedt <mar...@gm...> wrote: > Thanks! Here's a PR for the Sonar scan build configuration. > https://github.com/Netatalk/netatalk/pull/225 > > Once this gets merged to master I expect the quality gates to take effect. > > On Sat, Feb 25, 2023 at 12:54 PM Ralph Boehme <sl...@sa...> wrote: > >> On 2/25/23 20:02, Daniel Markstedt wrote: >> > Did you configure the Sonar secret for the GitHub action (on the GitHub >> > side)? >> >> should be done now. >> >> |
From: Daniel M. <mar...@gm...> - 2023-02-25 23:09:55
|
Thanks! Here's a PR for the Sonar scan build configuration. https://github.com/Netatalk/netatalk/pull/225 Once this gets merged to master I expect the quality gates to take effect. On Sat, Feb 25, 2023 at 12:54 PM Ralph Boehme <sl...@sa...> wrote: > On 2/25/23 20:02, Daniel Markstedt wrote: > > Did you configure the Sonar secret for the GitHub action (on the GitHub > > side)? > > should be done now. > > |
From: Ralph B. <sl...@sa...> - 2023-02-25 20:55:07
|
On 2/25/23 20:02, Daniel Markstedt wrote: > Did you configure the Sonar secret for the GitHub action (on the GitHub > side)? should be done now. |
From: Daniel M. <mar...@gm...> - 2023-02-25 20:22:19
|
Hi Ralph, all, I propose cutting a 2.2.8 release in the not-too-distant future. There are two pending PRs that should round out what I had in mind. https://github.com/Netatalk/netatalk/pull/222 https://github.com/Netatalk/netatalk/pull/223 After this I'll pivot to the main development branch and see how far I can get grafting AppleTalk back into place. Draft for a 2.2.8 changelog: https://github.com/Netatalk/netatalk/pull/224 Changes in 2.2.8 ================ * NEW: asip-status.pl: IPv6 support; show GSS-UAM SPNEGO blob; improved layout of output. * NEW: apple_dump: support for EA meta data. * NEW: Import netatalk-doc into the main repo, and overhaul scripts, man pages and html manual sources. * UPD: Display the Netatalk Daemon icon with the '-icon' afpd.conf option for all platforms. GH #214 * UPD: Remove OpenSSL 1.0 backwards compatibility header. Please use OpenSSL 1.1 or later. * UPD: configure: Enable DDP, timelord, and a2boot by default. GH #215 * UPD: configure: Disable Quota by default. GH #198 * FIX: afpd: Create tmp files in /tmp rather than / and clean up after use. Regression in 2.2.7. GH #188 * FIX: Provide MNTTYPE_NFS for Solaris descendents to enable compiling with Quota. GH #117 * FIX: afpd: reading from file may fail. SF Bug #619 * FIX: timelord: Fall back to timezone when tm_gmtoff is unavailable. Makes it work on Solaris descendents. GH #194 * FIX: fix largefile-check macro for largefile with clang 16. * FIX: Typo fixes in user facing strings. |
From: Daniel M. <mar...@gm...> - 2023-02-25 19:02:40
|
Did you configure the Sonar secret for the GitHub action (on the GitHub side)? This is a requirement for getting the analysis set up. On Sat, Feb 25, 2023 at 10:33 AM Ralph Boehme <sl...@sa...> wrote: > On 2/25/23 19:28, Ralph Boehme wrote: > > On 2/25/23 18:59, Daniel Markstedt wrote: > >> What do you think? > > it's your playing field, just let me know what colour you would prefer > > for the ball. :))) > > > > I just checked in github and I don't see any pending approvals or > > related notifications. > > ah, I missed the mail from github... > > So now I've clicked a few places and basic Sonarcloud setup should be done. > > https://sonarcloud.io/project/configuration?id=Netatalk_netatalk > > Is this enough to give you admin level access? > > Anything missing? > > -slow > > -- > Ralph Boehme, Samba Team https://samba.org/ > SerNet Samba Team Lead https://sernet.de/en/team-samba > > |
From: Ralph B. <sl...@sa...> - 2023-02-25 18:33:30
|
On 2/25/23 19:28, Ralph Boehme wrote: > On 2/25/23 18:59, Daniel Markstedt wrote: >> What do you think? > it's your playing field, just let me know what colour you would prefer > for the ball. :))) > > I just checked in github and I don't see any pending approvals or > related notifications. ah, I missed the mail from github... So now I've clicked a few places and basic Sonarcloud setup should be done. https://sonarcloud.io/project/configuration?id=Netatalk_netatalk Is this enough to give you admin level access? Anything missing? -slow -- Ralph Boehme, Samba Team https://samba.org/ SerNet Samba Team Lead https://sernet.de/en/team-samba |
From: Ralph B. <sl...@sa...> - 2023-02-25 18:28:51
|
On 2/25/23 18:59, Daniel Markstedt wrote: > What do you think? it's your playing field, just let me know what colour you would prefer for the ball. :))) I just checked in github and I don't see any pending approvals or related notifications. Just let me know how I can set this up and I'll do it. Cheers! -slow -- Ralph Boehme, Samba Team https://samba.org/ SerNet Samba Team Lead https://sernet.de/en/team-samba |