8.0.3 RELEASE coming soon

[gcooper]

Just for the record, an APC Smart-UPS 750, could not connect neither with the usb driver/ neither with the apcsmart on the serial port. I kept getting connection refused the usb driver responded that my device is not yet supported? (retelling from memory as I don't have it handy right now)

So one more vote for NUT upgrading (however not sure if it will solve my problem :)

Release notes suggest that going from 2.4.1 to 2.4.2 indicate that they fixed some USB interoperability issues. That being said, unless someone can test out a trunk image very quickly to verify whether or not things are truly fixed I'm not convinced that upgrading NUT alone will actually improve things as I don't have the hardware in-house to verify the new version with (in fact, it might regress things further, which is what I'm trying to avoid :/..).

If it does fix things, then I'll upgrade NUT and net-snmp (dependency) -- but this along with anonymous bind with ldap are the last items that need to go into 8.0.3. After that I'm drawing a line in the sand, test, test, test, and start rolling things up into an RC. If all goes well I'm hoping for a release either by the end of this week or early next week.

 

[gcooper]

I just tried to import a 1GB NTFS formatted flash drive with Beta-1 and got "An error occurred while labeling the disk.".

I'm not sure if you've done any work on this, but in case you have or plan to, I thought I'd let you know it's still broken.

I also tried manually loading /usr/local/modules/fuse.ko and then doing the import again and got the same error.

I don't understand, I thought my workaround for loading fuse.ko was working before. I had/have a ticket opened for this and MSDOSFS since before 8.0.1?

I've been a bit busy today getting all the ducks in line. I'll try tracking down the ticket and see if I can isolate / fix the problem before 8.0.3 BETA3 (this will be the last beta -- I hope)...

 

[gcooper]

I can understand the need for error checking, but what if you want to edit an entry? Sorry, I still haven't tried it, I just saw your reply. I just have quite a few entries and entering them will be one thing, but commenting them out/disabling something/editing them will be another. I think it might need adjusting.

Huh? /boot/loader.conf is in the upgrade/full install image and gets wiped out every time someone upgrades / installs. This is part of the reason why we added the "loader" / sysctl support is multifold:

1. Allow people to safely hack settings that changed system behavior without having their settings get wiped out every time they upgraded their machines/VMs [*].
2. Allow people to load drivers on demand if they weren't in the default kernel images (say someone had a machine with a controller that worked with the xhci driver -- they shouldn't be penalized for having compatible hardware.

[*] If you set some tunables and sysctls to bad values, you can 'brick' your box (until you change the tunable temporarily via the FreeBSD bootloader) or can performance severely degrade or improve (it depends on the machine and the setup).

Also, people need to be warned before upgrading that their existing tuneables will get wiped unless you have a method for importing them into the new system?

Edit: ok, I properly tested it and I see how the editing works and it's fine. I still think multiple entries is a hassle and warning/importing tuneables before upgrading to 8.0.3 should be done.

This is a one time thing though, so the change shouldn't be large. After that, it's effectively a no-op.

 

[ProtoSD]

I've been a bit busy today getting all the ducks in line. I'll try tracking down the ticket and see if I can isolate / fix the problem before 8.0.3 BETA3 (this will be the last beta -- I hope)...

Here's the ticket so you don't have to dig it up: http://support.freenas.org/ticket/759

There's also this post with a traceback when trying to import UFS (and a workaround in the one following it):

http://forums.freenas.org/showthrea...g-ufs-filesystem&p=12860&viewfull=1#post12860

They are probably unrelated problems, but both related to importing.

 

[gcooper]

Here's the ticket so you don't have to dig it up: http://support.freenas.org/ticket/759

The fusefs issue is easy to fix. The problem is that the port was broken.

There's also this post with a traceback when trying to import UFS (and a workaround in the one following it):

http://forums.freenas.org/showthrea...g-ufs-filesystem&p=12860&viewfull=1#post12860

They are probably unrelated problems, but both related to importing.

Eh... I really don't want to touch this because it'd be a wasted effort as william has rototilled this section of code twice. I might be able to import some changes with baling wire and duct tape to make it work, but I wouldn't be confident of the result.

 

[gcooper]

And 8.0.3-BETA2 has been up for a few hours. Enjoy :D.

 

[ProtoSD]

Thanks! Just responded to your reply to my suggestion about renaming the distribution files from i386/AMD64 to x86 / x64. Thanks for fixing that!

Hopefully that'll make more sense to people and help prevent them from installing the incorrect distribution.

Thanks!
:) :) :)

 

[gcooper]

Thanks! Just responded to your reply to my suggestion about renaming the distribution files from i386/AMD64 to x86 / x64. Thanks for fixing that!

Hopefully that'll make more sense to people and help prevent them from installing the incorrect distribution.

No prob! I'll wrap that change into BETA3, which should be out on Thursday/Friday with an updated version of nut (let's put it this way -- if it's good enough for FreeNAS legacy -- it's good enough for us :D..) and anonymous LDAP support.

Samba interoperability will need to wait until the next release -- which will be [8.0.4 or] 8.2. I don't want to steal from the 8.2 limelight, but IMHO 8.2.0 is for early(-ish) adopters, and folks who are happy with the stability and status quo of 8.0.x should stick with 8.0.3 and/or 8.0.4.

Things have improved IMO, but I'm also a bit cynical when it comes to .0 releases ;)..

 

[John Homer H Alvero]

Will this release finally fix the OS X LDAP authentication and sharing issue? I've struggled to fix this one and finally gave up. I was able connect FN8.0.2 to OS X LDAP, I can already see users from "id","groups" commands. But somehow samba is not getting it's users from LDAP. Anyone one having this problem? Sorry for not giving a detailed report.

 

[gcooper]

Will this release finally fix the OS X LDAP authentication and sharing issue? I've struggled to fix this one and finally gave up. I was able connect FN8.0.2 to OS X LDAP, I can already see users from "id","groups" commands. But somehow samba is not getting it's users from LDAP. Anyone one having this problem? Sorry for not giving a detailed report.

Yep. It's fixed in 8.0.3 :).

 

[John Homer H Alvero]

Hello gcooper,

I appreciate your reply. Thanks a lot for efforts working on FreeNAS. I can't wait to see 8.0.3 coming out. Now I can restart my FreeNAS project.

 

[John Homer H Alvero]

Hello, is this supposed to be happening on 8.0.3Beta2?

[john@freenas] /var/log/samba# pdbedit -Lv john
add_new_domain_info: failed to add domain dn= sambaDomainName=FREENAS,dc=ldap,dc=domain,dc=com with: Invalid DN syntax
invalid DN
smbldap_search_domain_info: Adding domain info for FREENAS failed with NT_STATUS_UNSUCCESSFUL
Username not found!


I have anonymous binding enabled and also root bind dn and password set. It seems that samba is STILL not authentication from LDAP.

 

[gcooper]

Hello, is this supposed to be happening on 8.0.3Beta2?

[john@freenas] /var/log/samba# pdbedit -Lv john
add_new_domain_info: failed to add domain dn= sambaDomainName=FREENAS,dc=ldap,dc=domain,dc=com with: Invalid DN syntax
invalid DN
smbldap_search_domain_info: Adding domain info for FREENAS failed with NT_STATUS_UNSUCCESSFUL
Username not found!


I have anonymous binding enabled and also root bind dn and password set. It seems that samba is STILL not authentication from LDAP.

Anonymous bind with LDAP still isn't available in FreeNAS. It's something that I was working on for the 8.0.3 release; you identified another gap that I need to test.

 

[John Homer H Alvero]

Anonymous bind with LDAP still isn't available in FreeNAS. It's something that I was working on for the 8.0.3 release; you identified another gap that I need to test.

I actually do not mind anomymous or not anonymous as long as samba or properly authenticating from LDAP. Thanks

 

[joeschmuck]

Things have improved IMO, but I'm also a bit cynical when it comes to .0 releases ;)..

Nope, that's not cynical, that is experience talking :)

 

[logan54]

Hello gcooper,

thank for the freenas release
ddns/inadyn is is working again in BETA2 (no-ip.com)
anyhow during boot i get the message:
ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior.
Is this message OK?

logan54

 

[joeschmuck]

Hello gcooper,

thank for the freenas release
ddns/inadyn is is working again in BETA2 (no-ip.com)
anyhow during boot i get the message:
ZFS WARNING: Recommended minimum kmem_size is 512MB; expect unstable behavior.
Is this message OK?

logan54

Which version are you running, 64 or 32 bit, also how much RAM do you have?

 

[gcooper]

I actually do not mind anomymous or not anonymous as long as samba or properly authenticating from LDAP. Thanks

Ok. I'm tempted to just comment out the code until it's actually implemented, TBH. The following snippet should work based on my understanding of the nss_ldap.conf manpage, but it's untested:

Index: nanobsd/Files/etc/rc.d/ix-ldap
===================================================================
--- nanobsd/Files/etc/rc.d/ix-ldap (revision 9140)
+++ nanobsd/Files/etc/rc.d/ix-ldap (working copy)
@@ -83,12 +83,20 @@
cat >"${nssconf}" <<-EOF
host ${ldap_hostname}
base ${ldap_basedn}
- rootbinddn ${ldap_rootbasedn}
pam_password ${ldap_pwencryption}
nss_base_passwd ${ldap_usersuffix},${ldap_basedn}
nss_base_group ${ldap_groupsuffix},${ldap_basedn}
nss_override_attribute_value loginShell /bin/sh
EOF
+ if [ "$ldap_anonbind" = 1 ]; then
+ cat >>"${nssconf}" <<-EOF
+ uri ldap://${ldap_hostname}
+EOF
+ else
+ cat >>"${nssconf}" <<-EOF
+ rootbinddn ${ldap_rootbasedn}
+EOF
+ fi
if [ "${ldap_ssl}" = "start_tls" ]; then
save_certificate "${ldap_id}"

The patch is against trunk BTW.

 

[Daisuke]

Please tell me that Nginx will make it into 8.0.3. :)

 

[gcooper]

Please tell me that Nginx will make it into 8.0.3. :)

Nope ;). Hasn't even been remotely baked enough to be enabled in production images.