Jump to content
jonp

unRAID Project Roadmap Announcements

414 posts in this topic Last Reply

Recommended Posts

Bottom line:  until a case is made that speaks to both the technical merits warranting an upgrade along with sufficient support from more than 1-2 users that need the upgrade, this will not take over priority from our other features outlined in this very post.  I don't see how anyone can disagree with this logic...

 

Saying it should be updated it because it was previously promised does not disagree with that logic.

 

I don't use AFP, and I don't use v5, so you're not going to get a response from me, but this type of management puts a very sour taste in my mouth when it comes to unRAID. Running a business isn't just about providing a product. Maybe Tom Needs to hire someone in addition that gets that, because you don't seem to. My money is already invested in unRAID, but I'm going to have a hard time recommending this product to other people in the future because of stuff like this. Heck, I've already invested money into the non-existent FlexRAID tRAID Linux version a few months back because I've gotten so sick of how poor things are run here. I've got a few threads of cases made, but I've received little to no help. Now you're arguing that we should make a case before we get something already promised? I'm sorry, but that doesn't fly. Maybe if Lime Technology's track record was a little better when it came to stuff like that, it would be understandable, but as it stands now, it's not. I don't see how anyone can disagree with this logic...

Share this post


Link to post

Without a good reasons I for one don't want any time spent on AFP updates that could better to spent on UPS and mail support.  Those two have clear benefits.  If updating AFP has benefits beyond "goodwill" then it won't get my vote.  Otherwise they will lose my "goodwill" because re: slowing down ups and mail.

 

So the above is a bit tongue-in-cheek, but it is also sincere because your demand for movement on AFP is just as valid as my demand for movement on UPS and email support.

 

So given that, what other factors does LT have to weigh in their decision making process?

Share this post


Link to post

Please do NOT spend any of your time on AFP, until and unless someone presents a reasonable reason for you to do so.  "You said you would" is not a reasonable reason.  If there is a good, technical benefit, then fine, but spending time on something because someone insists that Tom said he would 6 or more months ago is not reason to put real progress on hold.  Tom promised LOTS of things in the last 3 years I've been coming here.  Some happened, most did not.

 

The "roadmap" presented earlier sounds very reasonable to me, and the items 'promised' for the next release all sound like a much higher priority than fulfilling a 'promise' made months ago, that seemingly one person may or may not benefit from.

 

I'm really getting tired of hearing "you said you would" as a reason for every demand that has no other benefit to MOST of the unRAID community.

 

Since jonp has started posting regularly here, I've seen a HUGE improvement in not only communications, but also results.  unRAID has moved forward more in the last 3-4 months that it had in the previous 3 years.  Continuing to scream about how terrible LimeTech is because of the residual sentiment from those previous years is NOT productive.

 

jonp seems to be listening to reasonable arguments for where LT should focus their efforts.  So, make a reasonable argument for something you'd like to see improved (like Cache Pool Support, Support for Multiple File Systems, Improved Plugin Management, E-mail Notifications, UPS Monitor / Shutdown) and I bet they get addressed, and added to unRAID sooner than later.

 

As far as I'm concerned, personally, anything Tom said prior to jonp arriving is null and void.  Tom may or may not be working on unRAID still, I don't know or care.  jonp has been very active, and supportive of our reasonable requests, so consider this a 'do over' and present reasonable statements for what you'd like to see improved, and I bet you see positive action.  Keep yelling "but Tom said..." and expect no results.

Share this post


Link to post

The few parts I actually understand from the update are native UPS and email support, which are very welcome as both are not easy to set up currently. Fortunately APCUPSD works flawlessly on my box, tested several times in real blackouts.

 

I'm surprised no one has asked for the option to add two parity drives. Or is that already in some road map, or hidden in the alphabet soup somewhere?

Share this post


Link to post

Here you go, lime-technology.com/forum/index.php?topic=31909.0

 

Read through that entire thread with respect to AFP.  Seems like a low number of people are requesting the upgrade (in fact, you were the only one asking for an upgrade, it appears everyone else was just asking for us to not drop support for it entirely).  I think we'll need to see more folks rally behind the cause to bump this up in the priority list of "to dos".  I realize Tom may have made a commitment here, but we're looking out for the best interests of our users as a whole.  Many users are reporting that Time Machine works fine under the current unRAID implementation.

 

Again, not looking to drop AFP here, just trying to understand why we need a clearly dying protocol to be upgraded right now.

 

EDIT:

 

As for Samba/NFS, I don't think you can make a case to say we should update AFP (a dying and terrible protocol) because we've updated other protocols so much.  Samba/NFS = more popular, more widely used, and is definitely going to be supported longer.  Apples (no pun intended) and oranges.

 

There is no making cases with LT if ur not a top 10 fan boy.

Not sure how you came to the conclusion I am the only one that wants this updated but that's fine I can read between the lines very well. Delay and in a few years AFP will finally be dropped, problem solved. Versus spending all of 25 mins to complie it. Your more than welcome to write it off as I am the only one who wants it.  Enjoy playing with your own ball. Popular statement handed out to members here, think it applys to LT here as well.

 

Madburg,

 

Please respond to my previous message about arguing for what benefits such an update would provide and why it is necessary.  I can't help you if you don't make a case.

 

UPDATE:  FYI, I am moving some of madburgs posts are being moved to the complaint/bilge forum where they belong.  The original requests that weren't hostile in nature will remain.

 

Where they belong? We'll check you out, deja Vu, someone recently posted how posts are conveniently deleted, moved, and not censored. Your spending more time doing this then compiling Netatalk. Great use of LT time, the virtualization guys will pay for this, and hate me for it. A polite $sshole is still an $sshole, lets not get things confused, power to censor doesn't make you right.

 

Not so much as arguments have been giving but issues raised, you are welcome to scour the forums and find them as each time something is promised to be looked into or fixed or updated and then lost in a thread and started later again, usually by someone else and this is the game that is played again and again. Im not sure why you think if I don't repeat everything posted throughout the years to YOU personally then theres' nothing to discuss. You just like playing with the ball by your lonely self. What your request is that I spend even more time than I have to put all the issues together for you and put an argument around it. Tell you what, you PM me I will give you my number, and get you access to my unraid server and show you first hand all the AFP issues.

 

Or if you feel the following is argument enough, unRAID 5.0.3 (2013-11-26) netatalk: upgrade to version 2.2.5 (23rd of July 2013)

 

Current netatalk 3.1.2

 

Changes in 3.1.2

 

FIX: Option "vol dbpath" was broken in 3.1.1

 

FIX: Spotlight: file modification date, bug #545

 

FIX: Improve reliability of afpd child handler

 

FIX: debian initscript: add 0 and 6 to Default-Stop. debian-bug#745520

 

FIX: put the Solaris share reservation after our locking stuff, bug #560.

 

UPD: Improve Linux quota behaviour

 

FIX: xattrs on *BSD, bug #562

 

NEW: afpd: support for using $u username variable in AFP volume definitions. FR#90.

 

FIX: getvolbypath returns incorrect volume, bug #563

 

FIX: fd leak when using appledouble = v2, bug #554

 

UPD: New options that control whether dbus and Tracker are started: start dbus and start tracker, both default to yes, FR#91

 

UPD: Spotlight: SPARQL query optimisations

 

Changes in 3.1.1

 

FIX: Add asprint() compatibility function for systems lacking it

 

FIX: Fix ressource fork name conversion. Bug #534.

 

FIX: Fix a bug where only the first configured UAM was loaded. Bug #537.

 

UPD: Add support for AFP 3.4. From FR #85.

 

FIX: Registering with mDNS crashed. Bug #540

 

FIX: Saving from applications like Photoshop may fail, because removing the ressource fork AppleDouble file failed. Bug #542.

 

FIX: dbd: remove orphaned ._ AppleDouble files. Bug #549.

 

NEW: afpd: Automatic conversion of ._ AppleDouble files created by OS X. Bug #550.

 

FIX: afpd: Fix a crash in of_closefork(). Bug #551.

 

FIX: dbd: Don’t print message "Ignoring .file" for every . file. Bug #552.

 

FIX: afpd: Don’t flood log with failed sys_set_ea() messages.

 

Changes in 3.0.8

 

FIX: dbd: remove orphaned ._ AppleDouble files. Bug #549.

 

FIX: afpd: Fix a crash in of_closefork(). Bug #551.

 

Changes in 3.0.7

 

FIX: Build fixes for the Kerberos UAM

 

UPD: Use dedicated exit code for AFP connections that were dropped by the client right after the TCP handshake

 

FIX: Fix ressource fork name conversion. Bug #534.

 

FIX: Fix a bug where only the first configured UAM was loaded. Bug #537.

 

FIX: Allow ad set to remove the "w" flag on folders. Bug #539.

 

FIX: Fix path handling in ad utility. Bug #538.

 

FIX: Workaround for a problem which cannot be advertized by Avahi. Bug #541.

 

FIX: Registering with mDNS crashed. Bug #540

 

FIX: Saving from applications like Photoshop may fail, because removing the ressource fork AppleDouble file failed. Bug #542.

 

FIX: macusers showed root user. Bug #495.

 

UPD: Add file pathname to logmessage parse_entries: bogus eid. FR#87.

 

Changes in 3.1.0

 

NEW: AFP Spotlight support with Gnome Tracker

 

NEW: New option "spotlight" (G/V)

 

NEW: Configure option --with-tracker-pkgconfig-version

 

NEW: Configure option --with-tracker-prefix

 

NEW: If Spotlight is enabled, launch our own dbus instance

 

NEW: New option "dbus daemon" (G)

 

UPD: Add configure option --with-afpstats for overriding the result of autodetecting dbus-glib presence

 

NEW: Add recvfile support with splice() on Linux. New global options "recvfile" (default: no) and "splice size" (default 64k).

 

NEW: CNID backend "mysql" for use with a MySQL server

 

FIX: Build fixes for the Kerberos UAM

 

UPD: Use dedicated exit code for AFP connections that were dropped by the client right after the TCP handshake

 

Changes in 3.0.6

FIX: charset conversion failed when copying from Mac OS 9. Bug #523.

 

UPD: Don’t force S_ISGID for directories on FreeBSD. Bug #525.

 

NEW: Add support for ZFS ACLs on FreeBSD with libsunacl. From FR#83.

 

FIX: Active Directory LDAP queries for ACL support with new options "ldap user filter" and "ldap group filter". Bug #526.

 

Changes in 3.0.6

 

FIX: charset conversion failed when copying from Mac OS 9. Bug #523.

 

UPD: Don’t force S_ISGID for directories on FreeBSD. Bug #525.

 

NEW: Add support for ZFS ACLs on FreeBSD with libsunacl. From FR#83.

 

FIX: Active Directory LDAP queries for ACL support with new options "ldap user filter" and "ldap group filter". Bug #526.

 

NEW: Option "vol dbnest", when set to true, the CNID database for a volume is stored in the volume root of a share in a directory .AppleDB like in Netatalk 2. Defaults to false. From FR#84.

 

FIX: Small fix in the DSI tickle handling. Bug #528.

 

UPD: Enhance handling of connection attempts when hitting the connection limit. Bug #529.

 

FIX: Saving from Word to a folder that is a symlink to a folder on another filesystem results in a crash of the afpd process and the save to fail. This happens only if the option "follow symlinks" is enabled. Bug #532.

 

FIX: Disable Kerberos UAM if AFP service principal name can’t be evaluated. Fixes bug #531.

 

FIX: Fix handling of large number of volumes. Bug #527.

 

NEW: Configure option --with-tbd which can be used to disable the use of the bundled tdb and use a system installed version.

 

Changes in 3.0.5

 

FIX: Fix a crash when using pam_winbind. Fixes bug #516.

 

NEW: New global/volume option "ignored attributes"

 

FIX: "afp listen" option failed to take IPv6 addresses. Bug #515.

 

FIX: Fix a possible crash in set_groups. Bug #518.

 

NEW: Send optional AFP messages for vetoed files, new option "veto messages" can be used to enable sending messages. Then whenever a client tries to access any file or directory with a vetoed name, it will be sent an AFP message indicating the name and the directory. From FR #81.

 

NEW: New boolean volume option "delete veto files". If this option is set to yes, then Netatalk will attempt to recursively delete any vetoed files and directories. FR #82.

 

UPD: systemd unit dir is /usr/lib/systemd/system .

 

FIX: Saving files from application like MS Word may result in the file loosing metadata like the Finder label. Bug #521.

 

Changes in 3.0.4

 

FIX: Opening files without metadata EA may result in an invalid metadata EA. Check for malformed metadata EAs and delete them. Fixes bug #510.

 

FIX: Fix an issue with filenames containing non-ASCII characters that lead to a failure setting the size of a files ressource fork. This affected application like Adobe Photoshop where saving files may fail. Fixes bug #511.

 

UPD: Enhance ACL mapping, change global ACL option map acl to take the following options: "none", "rights" (default), "mode". none = no mapping, this resembles the previous false/no setting rights = map ACLs to Finder UARights, this resembles the previous true/yes setting. This is the default. mode = map ACLs to Finder UARights and UNIX mode From FR #73.

 

FIX: Fix a possible crash in cname() where cname_mtouname calls dirlookup() where the curdir is freed because the dircache detected a dev/inode cache difference and evicted the object from the cache. Fixes bug #498.

 

FIX: Add missing include, fixes bug #512.

 

FIX: Change default FinderInfo for directories to be all 0, fixes bug 514.

 

NEW: New option "afp interfaces" which allows specifying where Netatalk listens for AFP connections by interface names. From FR #79.

 

Changes in 3.0.3

 

UPD: afpd: Increase default DSI server quantum to 1 MB

 

UPD: bundled libevent2 is now static

 

NEW: --with-lockfile=PATH configure option for specifying an alternative path for the netatalk lockfile.

 

UPD: systemd service file use PIDFile and ExecReload. From FR #70.

 

UPD: RedHat sysvinit: rm graceful, reimplement reload, add condrestart

 

FIX: Couldn’t create folders on FreeBSD 9.1 ZFS fileystems. Fixed bug #491.

 

FIX: Fix an issue with user homes when user home directory has not the same name as the username. Fixes bug #497.

 

UPD: Fix PAM config install, new default installation dir is $sysconfdir/pam.d/. Add configure option --with-pam-confdir to specify alternative path.

 

NEW: AFP stats about active session via dbus IPC. Client side python program afpstats. Requires dbus, dbus-glib any python-dbus. configure option --dbus-sysconf-dir for specifying dbus system security configuration files. New option afpstats (default: no) which determines whether to enable the feature or not.

 

NEW: configure option --with-init-dir

 

NEW: dtrace probes, cf include/atalk/afp_dtrace.d for available probes.

 

UPD: Reload groups when reloading volumes. FR #71.

 

FIX: Attempt to read read-only ._ rfork results in disconnect. Fixes bug #502.

 

FIX: File’s ressource fork can’t be read if metadata EA is missing. Fixes bug #501.

 

FIX: Conversion from adouble v2 to ea for directories. Fixes bug #500.

 

FIX: Error messages when mounting read-only filesystems. Fixes bug #504.

 

FIX: Permissions of ._ AppleDouble ressource fork after conversion from v2 to ea. Fixes bug #505.

 

UPD: Use FreeBSD sendfile() capability to send protocol header. From FR #75.

 

UPD: Increase IO size when sendfile() is not used. From FR #76.

 

FIX: Can’t set Finder label on symlinked folder with "follow symlinks = yes". Fixes bug #508.

 

FIX: Setting POSIX ACLs on Linux Fixes bug #506.

 

FIX: "ad ls" segfault if requested object is not in an AFP volume. Fixes bug #496.

 

Changes in 3.0.2

 

NEW: afpd: Put file extension type/creator mapping back in which had been removed in 3.0.

 

NEW: afpd: new option ad domain. From FR #66.

 

FIX: volumes and home share with symlinks in the path

 

FIX: Copying packages to a Netatalk share could fail, bug #469

 

FIX: Reloading volumes from config file was broken. Fixes bug #474.

 

FIX: Fix _device-info service type registered with dns-sd API

 

FIX: Fix pathname bug for FCE modified event.

 

FIX: Remove length limitation of options like "valid users". Fixes bug #473.

 

FIX: Dont copy our metadata EA in copyfile(). Fixes bug #452.

 

FIX: Fix an error where catalog search gave incomplete results. Fixes bug #479.

 

REM: Remove TimeMachine volume used size FCE event.

 

UPD: Add quoting support to [in]valid users option. Fixes bug #472.

 

FIX: Install working PAM config on Solaris 11. Fixes bug #481.

 

FIX: Fix a race condition between dbd and the cnid_dbd daemon which could result in users being disconnected from volumes when dbd was scanning their volumes. Fixes bug #477.

 

FIX: Netatalk didn’t start when the last line of the config file afp.conf wasn’t terminated by a newline. Fixes bug #476.

 

NEW: Add a new volumes option follow symlinks. The default setting is false, symlinks are not followed on the server. This is the same behaviour as OS X’s AFP server. Setting the option to true causes afpd to follow symlinks on the server. symlinks may point outside of the AFP volume, currently afpd doesn’t do any checks for "wide symlinks".

 

FIX: Automatic AppleDouble conversion to EAs failing for directories. Fixes bug #486.

 

FIX: dbd failed to convert appledouble files of symlinks. Fixes bug #490.

 

Changes in 3.0.1

 

NEW: afpd: Optional "ldap uuid encoding = string | ms-guid" parameter to afp.conf, allowing for usage of the binary objectGUID fields from Active Directory.

 

FIX: afpd: Fix a Solaris 10 SPARC sendfilev bug

 

FIX: afpd: Fix a crash on FreeBSD

 

FIX: afpd: Fixes open file handle refcounting bug which was reported as being unable to play movies off a Netatalk AFP share. Bug ID 3559783.

 

FIX: afpd: Fix a possible data corruption when reading from and writing to the server simultaniously under load

 

FIX: Fix possible alignment violations due to bad casts

 

FIX: dbd: Fix logging

 

FIX: apple_dump: Extended Attributes AppleDouble support for *BSD

 

FIX: handling of / and : in volume name

 

UPD: Install relevant includes necessary for building programs with installed headers and shared lib libatalk

 

UPD: libevent configure args to pick up installed version. Removed configure arg --disable-libevent, added configure args --with-libevent-header|lib.

 

UPD: gentoo initscript: merge from portage netatalk.init,v 1.1

 

REM: Remove --with-smbsharemodes configure option, it was an empty stub not yet implemented

 

Changes in 3.0

 

UPD: afpd: force read only mode if cnid scheme is last

 

REM: afpd: removed global option "icon"

 

FIX: CNID path for user homes

 

Changes in 3.0 beta2

 

UPD: Solaris and friends: Replace initscript with SMF manifest

 

FIX: Solaris and friends: resource fork handling

 

Changes in 3.0 beta1

 

UPD: afpd: Performance tuning of read/write AFP operations. New option "afp read locks" (default: no) which disables that the server applies UNIX byte range locks to regions of files in AFP read and write calls.

 

UPD: apple_dump: Extended Attributes AppleDouble support. (*BSD is not supported yet)

 

Changes in 3.0 alpha3

 

NEW: afpd: Per volume "login message", NetAFP bug ID #18

 

NEW: afpd: Cross-platform locking (share modes) on Solaris and derivates with Solaris CIFS/SMB server. Uses new Solaris fcntl F_SHARE share reservation locking primitives. Enabled by default, set global "solaris share reservations" option to false to disable it.

 

NEW: ad: ad set subcommand for changing Mac metadata on the server

 

UPD: unix charset is UTF8 by default vol charset is same value as unix charset by default

 

UPD: .AppleDesktop/ are stored in $localstatedir/netatalk/CNID (default: /var/netatalk/CNID), databases found in AFP volumes are automatically moved

 

FIX: afpd: Server info packet was malformed resulting in broken server names being displayed on clients

 

FIX: afpd: Byte order detection. Fixes an error where Netatalk on OpenIndiana returned wrong volume size information.

 

 

Share this post


Link to post

Changes in 3.0 alpha2

 

UPD: afpd: Store . as is and / as : on the server, don’t CAP hexencode as "2e" and "2f" respectively

 

UPD: afdp: Automatic name conversion, renaming files and directories containing CAP sequences to their not enscaped forms

 

UPD: afpd: Correct handling of user homes and users without homes

 

UPD: afpd: Perform complete automatic adouble:v2 to adouble:ea conversion as root. Previously only unlinking the adouble:v2 file was done as root

 

UPD: dbd: -C option removes CAP encoding

 

UPD: Add graceful option to RedHat init script

 

UPD: Add --disable-bundled-libevent configure options When set to yes, we rely on a properly installed version on libevent CPPFLAGS and LDFLAGS should be set properly to pick that up

 

UPD: Run ldconfig on Linux at the end of make install

 

FIX: afpd: ad cp on appledouble = ea volumes

 

FIX: dbd: ignore ._ appledouble files

 

REM: Volumes options "use dots" and "hex encoding"

 

Changes in 3.0 alpha1

 

NEW: Central configuration file afp.conf which replaces all previous files

 

NEW: netatalk: service controller starting and restarting afpd and cnid_metad as necessary

 

NEW: afpd: Extended Attributes AppleDouble backend (default)

 

UPD: CNID databases are stored in $localstatedir/netatalk/CNID (default: /var/netatalk/CNID), databases found in AFP volumes are automatically moved

 

UPD: Start scripts and service manifests have been changed to only start the new netatalk service controller process

 

UPD: afpd: UNIX privileges and use dots enabled by default

 

UPD: afpd: Support for arbitrary AFP volumes using variable expansion has been removed

 

UPD: afpd: afp_voluuid.conf and afp_signature.conf location has been changed to $localstatedir/netatalk/ (default: /var/netatalk/)

 

UPD: afpd: default server messages dir changed to $localstatedir/netatalk/msg/

 

UPD: dbd: new option -C for conversion from AppleDouble v2 to ea

 

REM: AppleTalk support has been removed

 

REM: afpd: SLP and AFP proxy support have been removed

 

REM: afpd: legacy file extension to type/creator mapping has been removed

 

REM: afpd: AppleDouble backends v1, osx and sfm have been removed

 

 

So when you state  "Samba/NFS = more popular, more widely used, and is definitely going to be supported longer. " I say longer, sure they will be supported longer and have more fixes well after AFP is dropped, but the logic that we should be on stuck on 2.2.5 because no one in LT can find the few minutes and keep a promise (especially now that we are supposed to see things change and for the better) or we don't need ALL the fix's that have been publish since netatalk 2.2.5. Thats not how anyone felt about samba nor the kernel update (finally), "come on, its 2014, for gods sake" right so cut the crap and produce a netatalk update. How many people know what exactly was fixed in samba or kernel you changed too? How about all the fixes for NFS? Just hold tight AFP is next.. now this, freakin JOKE!

 

And for your statement "And what happens if we push this out and someone has a problem with it?  We have to support it then."

 

Push, push what? its a download for those who which to try out a a BETA, hello! Besides I would be the only one impacted, since no one else is using this dying protocol. And you don't support anything anyway, expect for license keys.

 

I just LOVE how these statement are all bent when its convenient. 

Share this post


Link to post

Without a good reasons I for one don't want any time spent on AFP updates that could better to spent on UPS and mail support.  Those two have clear benefits.  If updating AFP has benefits beyond "goodwill" then it won't get my vote.  Otherwise they will lose my "goodwill" because re: slowing down ups and mail.

 

So the above is a bit tongue-in-cheek, but it is also sincere because your demand for movement on AFP is just as valid as my demand for movement on UPS and email support.

 

So given that, what other factors does LT have to weigh in their decision making process?

 

Yes you will be told it will hold up UPS and Mail support, because neither technology have ever made it to LT, so they are busy scratching their heads and its going to take a few months for this to be accomplished by Q3 so AFP will sadly not make it in.

 

I want ALL the core feature (UPS and email support included) so this is not at you jumperalex.

 

How many remember how I had to pull teeth, whine, b^tch, etc... to get Hdparm and Smartctrl updated by Tom, anyone?

 

Share this post


Link to post

Here you go, lime-technology.com/forum/index.php?topic=31909.0

 

Read through that entire thread with respect to AFP.  Seems like a low number of people are requesting the upgrade (in fact, you were the only one asking for an upgrade, it appears everyone else was just asking for us to not drop support for it entirely).  I think we'll need to see more folks rally behind the cause to bump this up in the priority list of "to dos".  I realize Tom may have made a commitment here, but we're looking out for the best interests of our users as a whole.  Many users are reporting that Time Machine works fine under the current unRAID implementation.

 

Again, not looking to drop AFP here, just trying to understand why we need a clearly dying protocol to be upgraded right now.

 

EDIT:

 

As for Samba/NFS, I don't think you can make a case to say we should update AFP (a dying and terrible protocol) because we've updated other protocols so much.  Samba/NFS = more popular, more widely used, and is definitely going to be supported longer.  Apples (no pun intended) and oranges.

 

I would definitely like AFP to be updated. AFP is the only protocol that works correctly with iTunes, as well as TimeMachine. Apple's SMB implementation is good, but has problems.

Share this post


Link to post

As far as I'm aware, Tom has already put in many hours of R&D to learn about AFP and how to implement version 3. I would say it's a waste of time not to continue down this path. Once it's 'stable', then leave it alone.

 

Currently, it's not completely stable, and it's a feature some people paid for in version 5.

Share this post


Link to post

and I still don't see a reasonable argument for upgrading, just more "but you said..."

 

useless.

 

What would you find reasonable? What do you know about AFP, what can I would post that you would find reasonable about AFP? Because after all you don't care for it so its useless.

 

How about while scanning media across the array, netatalk bombs (for a lack of better words) and keeps looping on the same file never ending until afp is stopped and restarted?

How about while watching a movie via AFP, exactly timed with spin down you have set, media is cut off and has to be restarted.

My friend your post is useless.

Share this post


Link to post
... a shetload of changes over a lot of versions ...

 

I can't argue with that.

 

Now the question: is it added to the 6.0-release schedule or 6.1 [shrug]. 

Share this post


Link to post

You beat me to it, but I was just going to say that something like this seems like it would make sense for a 6.x release (where x >= 1).

 

I gave up on AFP ages ago with unRAID, but I do have a dedicated TimeCapsule so it isn't too critical. I would love to see it improved, but not at the expense of what has already been outlined for a Q3 release. Surely that's reasonable.

Share this post


Link to post

As far as I'm concerned, personally, anything Tom said prior to jonp arriving is null and void.  Tom may or may not be working on unRAID still, I don't know or care.  jonp has been very active, and supportive of our reasonable requests, so consider this a 'do over' and present reasonable statements for what you'd like to see improved, and I bet you see positive action.  Keep yelling "but Tom said..." and expect no results.

 

Per the changelog for 6.0-beta6:

[pre]Summary of changes from 6.0-beta5a to 6.0-beta6

-----------------------------------------------

...

Known issues in this release

----------------------------

- slack: bonding driver interaction with dhcpcd is flaky, introduced delay as workaround.

- slack: the time setting "(UTC+10:00) Brisbane" is wrong: Brisbane does not use daylight

savings time like "(UTC+10:00) Camberra, Melbourne, Sydney".

- slack: no 32-bit executable support (a non-issue?)

************- netatalk: update to 3.1.x didn't happen yet****************

- webGui: help incomplete; a few rough edges remain

- emhttp: any file that is world-readable is accessible via http://Tower/mnt/... (which is to say a

file can be made non-accessible by making it non-world-readable).

[/pre]Emphasis added.

 

Correct me if I'm wrong (and I'm sure you will), but "didn't happen yet" as a known issue for the release implies to me that it will be coming sooner rather than later. If not, maybe amend it to read "and won't happen for the foreseeable future" or "and won't happen until 6.x." When another user posts the updates that have occurred in Netatalk from what I count to be 7 stable releases, you don't find that to be a reasonable argument for upgrading, and in fact you believe it to be a "useless" post?

 

In addition, do we need to provide proof of why it is important to upgrade something that was noteworthy enough to make the changelog as an issue? Also, if "Tom may or may not be working on unRAID", presumably this release was vetted by jonp. So...the reference to Netatalk/AFP is not "null and void," right?

 

I have attempted to use Time Machine with my server with mixed success. A review of the AFP subforum under 5.x support seems to indicate that it doesn't work well for a lot of people, and hasn't for some time. If it is as simple as updating Netatalk, this seems like a relatively small investment of time.

 

In addition, "just update the packages" is easier said than done.  This isn't about the time it takes to update the packages.  It's about stopping development on other core features for a time while we implement and test.  And what happens if we push this out and someone has a problem with it?  We have to support it then.

 

Considering the other items in the "known issue" section (ZOMG BRISBANE DOES NOT USE DAYLIGHT SAVINGS TIME), it seems like a pretty minor fix that will not require you to "stop development on other core features."

Share this post


Link to post

and I still don't see a reasonable argument for upgrading, just more "but you said..."

 

useless.

 

What would you find reasonable? What do you know about AFP, what can I would post that you would find reasonable about AFP? Because after all you don't care for it so its useless.

 

How about while scanning media across the array, netatalk bombs (for a lack of better words) and keeps looping on the same file never ending until afp is stopped and restarted?

How about while watching a movie via AFP, exactly timed with spin down you have set, media is cut off and has to be restarted.

My friend your post is useless.

 

I would find listing specific issues reasonable, for example, something like

 

...media scanning across the array (perhaps even with a comment about if it's a good or a bad thing, and what the newer version would do to benefit users), netatalk bombs (perhaps with an explanation of what that means, and how the newer version will make this situation better), keeps looping on the file until restarted, spin down forces a restart...

 

Telling jonp about these kinds of things, with specific examples and reasons how the new update will resolve these issues is FAR more likely to get him to care, than more "but you said..." posts.

 

Since my post seems to have forced you to list these items, and with specifics like these, AFP might get upgraded, I'd have to say my post was anything but useless.

Share this post


Link to post

No worries, there are many more issues but for anyone to say including LT that its a guarantee an updated version would resolve ALL issues is not possible by anyone.

Nor does a reference point exist or can be used by another system (non unRAID based) that the issues are solely Netatalk based, you have avahi in the mix and some issues can be say MD driver/fuse based spilling over. So until the update is provided no testing can be done under unRAID. That said I know its a dead end without an update to AFP otherwise, I know because I run AFP with maxdebug enabled and can see what is occurring, dont believe is something LT can fix because they don't own/code AFP. The wait has been long enough and overdue on this.

 

I have supported many issues to be resolved even when they were not issues for me. I pulled teeth to get Tom to fix the extended attribute bug with AFP, and provide all the data to do so.

 

I appreciate those who stepped up and chimed in, jonp has to deal with the old issue as well, its not a blank slate. Have to take the good with the bad, produce and things will change across the board. No reason a few steps back can't be taken with three people on board and knock these items out. At the end of the day we'll test them in real usage cases and provide feedback. No one beta was ever perfect. Not updating AFP is a slap in the face, and overdue, period.

 

P.S. as it was pointed out, Tom has learned a lot about AFP and I am certain and comfortable that he could pull off compiling an updated version with little to no change possible required after us testing. If Tom knows or notices something is off he always add that to the release notes for anyone to be on the look out for.

Share this post


Link to post

Yawn. AFP just like pretty much everything else with unRAID all comes back to the same thing... Slackware.

 

Lime Technologies has to spend HOURS / DAYS / MONTHS / YEARS trying to figure out all on their own how to do X, Y and Z in the OS. Reason being, Slackware has no community, documentation, blogs / web examples, wikis, forums, user base, package manager, packages, etc. Slackware is harder for LT, the user and why innovation / adding new features / functionality is very complex and takes FOREVER.

 

Everything you EVER wanted to know about AFP (2 or 3) and how to implement in other Linux OSes:

 

Arch Linux

 

Debian

 

CentOS

 

Ubuntu

 

Gentoo

 

If unRAID was on any other Linux Distro other than Slackware... An average person could follow any one of the 1,000+ guides on AFP and make version 2 or 3 work. For most distros, it's just "apt-get netatalk" and editing a conf file. It's LT (3 people) versus 100,000+ (Developers / Experts / Power Users) for each Linux Distro. For whatever reason, LT thinks that is bad idea and does not want you to be able to decide what you can / cannot do on your own server. It took an online petition and years just to get nano (128k editor) added so good luck with AFP.

 

Just imagine where unRAID would be if only 5 / 10 Linux Experts like me left the Community. These are the people that are coming up the ways / tools / documentation / innovation / How Tos. 90% of what we do is taking what every other Linux Distro on the planet can do and "backporting" it to Shitware. If I didn't have to manually compile 100+ programs (I'm force too with Slackware), I would / could blow you all away with all kinds of innovation / features / functionality that would make your life so much easier. It's a MAJOR PAIN to manage / update / add features and functionality to Slackware so I totally get why LT doesn't want to do it themselves.

 

However, that should be a freaking clue that you are doing something really wrong by using Slackware and continuing to stay with it is MADNESS.

Share this post


Link to post

Yawn. AFP just like pretty much everything else with unRAID all comes back to the same thing... Slackware.

 

Lime Technologies has to spend HOURS / DAYS / MONTHS / YEARS trying to figure out all on their own how to do X, Y and Z in the OS. Reason being, Slackware has no community, documentation, blogs / web examples, wikis, forums, user base, package manager, packages, etc. Slackware is harder for LT, the user and why innovation / adding new features / functionality is very complex and takes FOREVER.

 

Everything you EVER wanted to know about AFP (2 or 3) and how to implement in other Linux OSes:

 

Arch Linux

 

Debian

 

CentOS

 

Ubuntu

 

Gentoo

 

If unRAID was on any other Linux Distro other than Slackware... An average person could follow any one of the 1,000+ guides on AFP and make version 2 or 3 work. For most distros, it's just "apt-get netatalk" and editing a conf file. It's LT (3 people) versus 100,000+ (Developers / Experts / Power Users) for each Linux Distro. For whatever reason, LT thinks that is bad idea and does not want you to be able to decide what you can / cannot do on your own server. It took an online petition and years just to get nano (128k editor) added so good luck with AFP.

 

Just imagine where unRAID would be if only 5 / 10 Linux Experts like me left the Community. These are the people that are coming up the ways / tools / documentation / innovation / How Tos. 90% of what we do is taking what every other Linux Distro on the planet can do and "backporting" it to Shitware. If I didn't have to manually compile 100+ programs (I'm force too with Slackware), I would / could blow you all away with all kinds of innovation / features / functionality that would your life so much easier. It's a MAJOR PAIN to manage / update / add features and functionality to Slackware so I totally get why LT doesn't want to do it themselves.

 

However, that should be a freaking clue that you are doing something really wrong by using Slackware and continuing to stay with it is MADNESS.

 

You are not wrong....  Limetech must love and hate a community like this  ;D

Share this post


Link to post

Grumpy has made a lot of good points about moving away from Slackware (IMO). It would be nice to understand from LT the reasons to stay with Slackware.

 

**EDIT** I should probably add that my post is not indented in any way to cause arguments (sorry if it does). It's just good to get both sides of the story before jumping to conclusions.

Share this post


Link to post

Yup, same old set of issues popping up with the exact same old set of root causes -- a core OS Distro with total lack of community support and package management when compared to modern distros.

 

Limetech, let the entire rest of the Linux community (hundreds of thousands of users) help you out by providing their time and expertise in areas you frankly lack. Move to a core OS distro that is alive.

Share this post


Link to post

Grumpy has made a lot of good points about moving away from Slackware (IMO). It would be nice to understand from LT the reasons to stay with Slackware.

 

**EDIT** I should probably add that my post is not indented in any way to cause arguments (sorry if it does). It's just good to get both sides of the story before jumping to conclusions.

Yup, same old set of issues popping up with the exact same old set of root causes -- a core OS Distro with total lack of community support and package management when compared to modern distros.

 

Limetech, let the entire rest of the Linux community (hundreds of thousands of users) help you out by providing their time and expertise in areas you frankly lack. Move to a core OS distro that is alive.

+1 to both!

Share this post


Link to post

Grumpy has made a lot of good points about moving away from Slackware (IMO). It would be nice to understand from LT the reasons to stay with Slackware.

 

**EDIT** I should probably add that my post is not indented in any way to cause arguments (sorry if it does). It's just good to get both sides of the story before jumping to conclusions.

 

Do not have auto updates or a package manager is something Tom really appreciates, because it let the base OS untouched and maybe more stable. BUT this is a pain in the @ss to develop plugins, so people get angry about this.

 

I've been using Netatalk 3.1.0 (just updated to 3.1.2) for some time, 6 months maybe, and is by FAR more stable than v2. The problem is where to put the DB files that are by default stored in /var directory. Tom once asked me about the system impact of storing them on a volatile media, like the RAMFS, and I told him it never consumed more than 250MB of RAM, even with thousands of inodes mapped. I perceived he felt uncomfortable with that setup, even after I assured him the databases are regenerated after a reboot.

 

Compiling Netatalk is easy, managing it from the emhttp service is another discussion.

Share this post


Link to post

gfjardim, can you provide a slackbuild for 3.x and/or a 64bit package for others to test with?

Does it have other dependencies that need to be satisfied first?

Can it just be dropped into the /boot/extra folder?

Share this post


Link to post

Do not have auto updates or a package manager is something Tom really appreciates, because it let the base OS untouched and maybe more stable.

 

Wait... What?!?

 

Do you honestly believe that unRAID (using Slackware) is more stable than CentOS (which 30% of all the web servers in the world run), Debian, Red Hat, etc? Do you think our little piss ant home servers are doing anything close to what Enterprises are on their servers using Red Hat, Debian, CentOS, OpenSUSE, etc? Are you suggesting that I tell all my clients that what they are doing is wrong and to remove Red Hat from all their Servers? To stop using a Package Manager to update, fix Bugs, Apply Security Patches, etc? Convince them their support costs should skyrocket due to how complex / difficult it is to support Slackware on a single server and 1,000+ throughout the Enterprise?

 

A package manager doesn't make a Linux more / less stable... The packages and Linux Kernel do.

 

Do you honestly think CentOS / Red Hat / Debian and all their Package Maintainers (we are talking about thousands of people who work / maintain specific packages) know less about which packages (versions, patches, etc) are more stable or not than one person, Tom? Do you think they do not have EXTENSIVE and WELL DEFINED testing / alpha / beta and roll out strategies for each package and supporting it through various versions?

 

Just using ONE package as an example (everyone single one of their packages has this): Debian GCC

 

Please include a link / wiki / document on unRAID where Tom has a TEAM of package maintainers keeping track of bugs, versions, dependencies, news, updates, patches, alpha / beta testing, etc. for each of the packages in unRAID.

 

BUT this is a pain in the @ss to develop plugins, so people get angry about this.

 

Agreed but I also do not want to be running 4+ year old programs that have have a dozen security advisories or memory leaks either.

 

Call me crazy... If BILLION DOLLAR corporations who have BILLIONS of dollars and Petabyte, Exabyte, Zettabytes of data at risk... Trust and use those Linux Distros, I think we can trust them for our piss ant home servers too.

 

Like I said earlier in this thread... I'd like someone to name just ONE Linux Server Appliance or Linux Distro that runs on Slackware besides unRAID.

 

Proxmox (Debian), XenServer (CentOS), Neth Server (CentOS), Clear OS (Red Hat), SME Server (CentOS), Turnkey Linux (Debian), etc.

 

There isn't a person (mostly Linux noobs) on this forum that is going to convince me or any of those companies above that they choose an inferior unstable Linux Distro nor will you get them to switch to Slackware. Also, there hasn't been a Linux Distro based on Slackware in the last 5+ years and you will not see one again. To me, that tells me / you everything that you need to know.

Share this post


Link to post

I've been using Netatalk 3.1.0 (just updated to 3.1.2) for some time, 6 months maybe, and is by FAR more stable than v2. The problem is where to put the DB files that are by default stored in /var directory. Tom once asked me about the system impact of storing them on a volatile media, like the RAMFS, and I told him it never consumed more than 250MB of RAM, even with thousands of inodes mapped. I perceived he felt uncomfortable with that setup, even after I assured him the databases are regenerated after a reboot.

 

Compiling Netatalk is easy, managing it from the emhttp service is another discussion.

 

Easy as in your sleep? Like others have? Well that's not their stance, it will deviate from this new roadmap. Promises, statements, release notes cannot be held as commitments the way it's being communicated.

 

As for the DB that is easy for some then others. I'll explain, since AFP was promoted in unRAID v5 nothing was ever done for noobs to be able to manage it. So I for one (others have similar solutions) have a vmdk dedicated for the DB, auto mounted out side of the array, before AFP starts. What does that do? Survives reboots, closes the DB properly on shutdown/reboots.

So again we aren't even asking for DB solution just for it be updated to the latest version. Why did we change from SMBv1? Why change to SMBv2 to 3?

How long did that take to compile?

Share this post


Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.