Although samba-4 isn't out yet (and it'll probably take a lot of time until it will), here's a bug to track and collect the activity from non-developer contributors and volunteers.
Tiziano, thanks for creating this metabug. According to our little conversation, I'll attach both my ebuilds: samba-4.0.0_alpha1.ebuild to build the alpha1 version of Samba4. samba4-9999.ebuild to build from SVN (unfinished). Both ebuilds need the "config" directory from /usr/portage/net-fs/samba/files in their ${FILESDIR} - patches are not necessary. Note that both ebuilds work for me only with USE="-python", which could be based on the fact that I still use Python 2.4. Maybe someone wants to try Python 2.5 and report back here. Any corrections and suggestions are welcome, since I plan to go into production with Samba 4 the day it is released... Regards, Torsten
Created attachment 133542 [details] Samba 4 SVN ebuild
Created attachment 133543 [details] Samba 4 alpha ebuild
I'm testing this with an up-to-date system and python-2.5.1. The latest version is alpha3, I just changed the filename. Compiling the python modules still fail. cp lib/events/events.py bin/python/events.py Compiling nsswitch/winbind_nss_linux.c Linking bin/static/libnss_winbind.a Linking bin/shared/libdcerpc.so.0.0.1 Linking bin/shared/libdcerpc_samr.so.0.0.1 Linking bin/shared/libtorture.so.0.0.1 Linking bin/shared/libldb.so.0.0.1 Linking bin/shared/libgensec.so.0.0.1 Linking bin/shared/libndr.so.0.0.1 Linking bin/shared/libregistry.so.0.0.1 Linking bin/shared/libnss_winbind.so.2 make: *** Kohteen "python_ext" tuottamiseen ei ole sääntöä. Seis.
(In reply to comment #4) > I'm testing this with an up-to-date system and python-2.5.1. > The latest version is alpha3, I just changed the filename. Compiling the python > modules still fail. > [...] > make: *** Kohteen "python_ext" tuottamiseen ei ole sääntöä. Seis. My bad! I'm just attending the SambaXP conference and realized during a talk by Andrew Bartlett, that Python is now a build dependency for Samba 4. Thus, we can throw away the python use flag. The make target python_ext has gone, but (I'll point that out the Samba team this afternoon) the python modules are not (yet) correctly installed by make install. I'll report back the results. Regards, Torsten
Folks, yesterday on SambaXP, Jelmer Vernooij explained the Python integration for Samba 4 in more detail. In fact, all support tools, e.g. SWAT, will sooner or later be rewritten in Python. At the moment, the standard build process creates a binary called "smbpython" in the bin/ directory of the source distribution. This is a wrapper for the actual host-Python, which correctly imports the Samba modules. Since the Samba 4 developer team momentarily consists of only 5 members, a correct install of the Python modules does not have highest priority. In fact, they're just trying to figure out, how to install all the Python stuff correctly on all supported platforms. That's why where's still no install target for that in the Makefile. Maybe there's someone here willing to contribute code or knowledge?! According to the Samba team, contributions are always welcome, especially in regard to the slow movement of Samba 4. At the moment there are doubts, that the first beta will be out until the end of the year! Regards, Torsten
Heloo. I copied samba-4.0.0_alpha1 to alpha3 and trying to install samba-4.0.0_alpha3 >>> Emerging (1 of 1) net-fs/samba-4.0.0_alpha3 to / * samba-4.0.0alpha3.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ] * checking ebuild checksums ;-) ... [ ok ] * checking auxfile checksums ;-) ... [ ok ] * checking miscfile checksums ;-) ... [ ok ] * checking samba-4.0.0alpha3.tar.gz ;-) ... [ ok ] >>> Unpacking source... >>> Unpacking samba-4.0.0alpha3.tar.gz to /var/tmp/portage/net-fs/samba-4.0.0_alpha3/work >>> Source unpacked. >>> Compiling source in /var/tmp/portage/net-fs/samba-4.0.0_alpha3/work/samba-4.0.0alpha3 ... sed: can't read Makefile.in: No such file or directory * * ERROR: net-fs/samba-4.0.0_alpha3 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2996: Called die * The specific snippet of code: * sed -i -e 's/^\(install:.*\)installswat \(.*\)/\1\2/' Makefile.in || die "sed failed"; * The die message: * sed failed * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/net-fs/samba-4.0.0_alpha3/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-fs/samba-4.0.0_alpha3/temp/environment'. * This ebuild is from an overlay: '/usr/local/portage/' What is wrong ?
(In reply to comment #7) > Heloo. I copied samba-4.0.0_alpha1 to alpha3 and trying to install > samba-4.0.0_alpha3 > >>> Emerging (1 of 1) net-fs/samba-4.0.0_alpha3 to / > * samba-4.0.0alpha3.tar.gz RMD160 SHA1 SHA256 size ;-) ... > [ ok ] > * checking ebuild checksums ;-) ... > [ ok ] > * checking auxfile checksums ;-) ... > [ ok ] > * checking miscfile checksums ;-) ... > [ ok ] > * checking samba-4.0.0alpha3.tar.gz ;-) ... > [ ok ] > >>> Unpacking source... > >>> Unpacking samba-4.0.0alpha3.tar.gz to /var/tmp/portage/net-fs/samba-4.0.0_alpha3/work > >>> Source unpacked. > >>> Compiling source in /var/tmp/portage/net-fs/samba-4.0.0_alpha3/work/samba-4.0.0alpha3 ... > sed: can't read Makefile.in: No such file or directory > * > * ERROR: net-fs/samba-4.0.0_alpha3 failed. > * Call stack: > * ebuild.sh, line 49: Called src_compile > * environment, line 2996: Called die > * The specific snippet of code: > * sed -i -e 's/^\(install:.*\)installswat \(.*\)/\1\2/' Makefile.in > || die "sed failed"; > * The die message: > * sed failed > * > * If you need support, post the topmost build error, and the call stack if > relevant. > * A complete build log is located at > '/var/tmp/portage/net-fs/samba-4.0.0_alpha3/temp/build.log'. > * The ebuild environment file is located at > '/var/tmp/portage/net-fs/samba-4.0.0_alpha3/temp/environment'. > * This ebuild is from an overlay: '/usr/local/portage/' > What is wrong ? > if ! use swat ; then sed -i \ -e 's/^\(install:.*\)installswat \(.*\)/\1\2/' \ Makefile.in || die "sed failed" fi s/Makefile.in/Makefile/
I found a workaround for the sed/Makefile.in issue. Just add 'swat' to your USE flags.
Created attachment 189826 [details] samba4 alpha7 ebuild Working ebuild for samba4 alpha7.
(In reply to comment #10) > Created an attachment (id=189826) [edit] > samba4 alpha7 ebuild > > Working ebuild for samba4 alpha7. > I have problems with compiling tdb and tevent as external packages, cause they want to overwrite some files samba4 installed (/usr/lib/python2.6/site-packages/tdb.so and /usr/lib/python2.6/site-packages/tevent.so). But I need those packages for compiling libmapi. Can somebody help me? I will attach the other ebuilds here.
Created attachment 189917 [details] talloc for samba4 and libmapi Please don't be cross with me for this, these are my first ebuilds.
Created attachment 189918 [details] tevent for samba4 and libmapi Please don't be cross with me for this, these are my first ebuilds.
Created attachment 189919 [details] tdb for samba4 and libmapi Please don't be cross with me for this, these are my first ebuilds.
Created attachment 189964 [details] Simplified Samba 4.0.0_alpha7 ebuild I somewhat cleaned up and simplified the ebuild for Samba-4.0.0_alpha7. Please note the following facts: * Samba 4 is far from being complete! Especially: - Printing - CIFS/SMB mount helpers - the "net" command - the new SWAT and several other parts are not (yet/fully) implemented and/or buggy. * It comes with almost no documentation whatsoever - lots of manpages are still missing - the package comes without README and such - if you switch on the "doc" use flag, you should find files like "BUGS", "TODO", etc. in /usr/share/doc/samba-4.0.0_alpha7 - Some documentation is provided via SambaWiki (s.b.) * Active directory serving works very well for small to medium sized domains - There are several production sites running now with 20-50 Windows-Clients. I now cleaned out almost all "extra" stuff from the ebuild that has been inherited from Samba 3.x. Also, I changed the init scripts to properly start the new samba-daemon from /usr/sbin/samba. They go into ${FILESDIR}/config-4.0. (See attachment samba-4.0.0_alpha7-files.tar.bz2) I DO NOT recommend using Samba 4 on a production desktop system, since most of the client features don't work as of yet. Anyway, you SHOULD try the new active directory serving capabilities and report any bugs and glitches directly to the samba team via https://bugzilla.samba.org/ Be sure to read the Howtos and setup guides on http://wiki.samba.org/index.php/Samba4 Good luck!
Created attachment 189965 [details] New content for ${FILESDIR}
Created attachment 189972 [details] Bugfixed samba-4.0.0_alpha7.ebuild There's a minor configure-bug that is (hopefully) circumvented by this ebuild: ./configure --sysconfdir=/etc creates /etc/samba on make install, which is never used. Accordingly, ./configure --sysconfdir=/etc/samba creates /etc/samba/samba, which is now removed to avoid confusion. Best regards, Torsten
fyi - collision on app-arch/rpm-5.1.6 (/usr/lib64/perl5/5.8.8/x86_64-linux/perllocal.pod) and samba-4.0.0alpha8 is out.
Anyone already made a samba 4 alpha 8 ebuild? Especially with split samba packages support so I can try setting up samba franky.
(In reply to comment #19) > Anyone already made a samba 4 alpha 8 ebuild? Especially with split samba > packages support so I can try setting up samba franky. I'd be highly interested in this, too! Ewoud, maybe we can cooperate and make a valid split set of alpha 8 ebuilds that might have a chance to make it into portage (or into Tiziano's overlay... ;-)
(In reply to comment #20) > (In reply to comment #19) > > Anyone already made a samba 4 alpha 8 ebuild? Especially with split samba > > packages support so I can try setting up samba franky. > > I'd be highly interested in this, too! > > Ewoud, maybe we can cooperate and make a valid split set of alpha 8 ebuilds > that might have a chance to make it into portage (or into Tiziano's overlay... > ;-) > Though I don't have much experience, I would be interested. I have a few possible goals we could try: - A fully working samba franky (I'd be willing to write the documentation to get it running) - Split the samba4 ebuild attached into samba-{client,libs,server} like the current samba packages - Update the samba4-9999.ebuild to reflect the SVN => git switch. Think we could talk more about this on IRC?
(In reply to comment #21) > [...] possible goals we could try: > - A fully working samba franky (I'd be willing to write the documentation to > get it running) > - Split the samba4 ebuild attached into samba-{client,libs,server} like the > current samba packages > - Update the samba4-9999.ebuild to reflect the SVN => git switch. All of these goals sound desirable (and even reasonable ;-) to me. > Think we could talk more about this on IRC? Definitely, but only next week, since I'm on a conference until friday. Which server/port/channel do you prefer?
Created attachment 211088 [details] samba-libs-4.0.0_alpha8.ebuild Hi folks, find attached a first (probably non-working) beginning of a samba-4.0.0alpha8 split ebuild. Please, put the ebuild into net-fs/samba-libs on your local overlay and run: ebuild path/to/samba-libs-4.0.0_alpha8.ebuild digest clean prepare configure compile and report back with your individual results. I can't get past the following error: [...] Compiling ../librpc/gen_ndr/ndr_atsvc.c Partially linking bin/mergedobj/ndr_atsvc.o Compiling librpc/rpc/dcerpc.c librpc/rpc/dcerpc.c:27:37: Fehler: librpc/rpc/dcerpc_proto.h: Datei oder Verzeichnis nicht gefunden librpc/rpc/dcerpc.c: In Funktion »dcerpc_connection_init«: librpc/rpc/dcerpc.c:79: Fehler: »dcerpc_generic_session_key« nicht deklariert (erste Benutzung in dieser Funktion) librpc/rpc/dcerpc.c:79: Fehler: (Jeder nicht deklarierte Bezeichner wird nur einmal aufgeführt librpc/rpc/dcerpc.c:79: Fehler: für jede Funktion in der er auftritt.) librpc/rpc/dcerpc.c: In Funktion »ncacn_push_request_sign«: librpc/rpc/dcerpc.c:343: Fehler: Implizite Deklaration der Funktion »ncacn_push_auth« librpc/rpc/dcerpc.c:343: Fehler: inkompatible Typen in return librpc/rpc/dcerpc.c:353: Fehler: inkompatible Typen in return librpc/rpc/dcerpc.c:356: Fehler: inkompatible Typen in return librpc/rpc/dcerpc.c:451: Warnung: format »%u« erwartet Typ »unsigned int«, aber Argument 2 hat Typ »size_t« librpc/rpc/dcerpc.c:451: Warnung: format »%u« erwartet Typ »unsigned int«, aber Argument 5 hat Typ »size_t« librpc/rpc/dcerpc.c: In Funktion »dcerpc_bind_send«: librpc/rpc/dcerpc.c:727: Fehler: inkompatible Typen in Zuweisung librpc/rpc/dcerpc.c: In Funktion »dcerpc_auth3«: librpc/rpc/dcerpc.c:800: Fehler: inkompatible Typen in Zuweisung librpc/rpc/dcerpc.c: In Funktion »dcerpc_alter_context_send«: librpc/rpc/dcerpc.c:1665: Fehler: inkompatible Typen in Zuweisung The following command failed: x86_64-pc-linux-gnu-gcc -march=nocona -Os -mfpmath=sse -msse3 -pipe -g -DDEBUG_PASSWORD -DDEVELOPER -Wall -Wshadow -Werror-implicit-function-declaration -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wmissing-format-attribute -Wformat=2 -Wdeclaration-after-statement -Wunused-macros -Wno-format-y2k -Wno-unused-parameter -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -march=nocona -Os -mfpmath=sse -msse3 -pipe -g -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/ldb_tdb -Ilib/ldb/include -Ilib/ldb/include -Ilib/events -I../lib/tevent -Ilib/replace -march=nocona -Os -mfpmath=sse -msse3 -pipe -g -fPIC -I./include -I. -I./lib -I./../lib/replace -I./../lib/talloc -I./.. -D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H -c librpc/rpc/dcerpc.c -o librpc/rpc/dcerpc.o make: *** [librpc/rpc/dcerpc.o] Fehler 1 * ERROR: net-fs/samba-libs-4.0.0_alpha8 failed: * emake libraries failed * * Call stack: * ebuild.sh, line 55: Called src_compile * environment, line 3561: Called die * The specific snippet of code: * emake libraries || die "emake libraries failed" * * If you need support, post the output of 'emerge --info =net-fs/samba-libs-4.0.0_alpha8', * the complete build log and the output of 'emerge -pqv =net-fs/samba-libs-4.0.0_alpha8'. * This ebuild is from an overlay named 'local': '/usr/local/portage/' * The complete build log is located at '/var/tmp/portage/net-fs/samba-libs-4.0.0_alpha8/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-fs/samba-libs-4.0.0_alpha8/temp/environment'. * S: '/var/tmp/portage/net-fs/samba-libs-4.0.0_alpha8/work/samba-4.0.0alpha8/source4' Anyone else who is getting this (or perhaps has a fix ;-)? Thanks in advance for testing. Regards, Torsten
P.S. Sorry for the German error messages. I just realized that I didn't reset LC_ALL to C before compiling... ;-) Anyway, the error persists with LC_ALL=C: Compiling librpc/rpc/dcerpc.c librpc/rpc/dcerpc.c:27:37: error: librpc/rpc/dcerpc_proto.h: No such file or directory librpc/rpc/dcerpc.c: In function 'dcerpc_connection_init': librpc/rpc/dcerpc.c:79: error: 'dcerpc_generic_session_key' undeclared (first use in this function) librpc/rpc/dcerpc.c:79: error: (Each undeclared identifier is reported only once librpc/rpc/dcerpc.c:79: error: for each function it appears in.) librpc/rpc/dcerpc.c: In function 'ncacn_push_request_sign': librpc/rpc/dcerpc.c:343: error: implicit declaration of function 'ncacn_push_auth' librpc/rpc/dcerpc.c:343: error: incompatible types in return librpc/rpc/dcerpc.c:353: error: incompatible types in return librpc/rpc/dcerpc.c:356: error: incompatible types in return librpc/rpc/dcerpc.c:451: warning: format '%u' expects type 'unsigned int', but argument 2 has type 'size_t' librpc/rpc/dcerpc.c:451: warning: format '%u' expects type 'unsigned int', but argument 5 has type 'size_t' librpc/rpc/dcerpc.c: In function 'dcerpc_bind_send': librpc/rpc/dcerpc.c:727: error: incompatible types in assignment librpc/rpc/dcerpc.c: In function 'dcerpc_auth3': librpc/rpc/dcerpc.c:800: error: incompatible types in assignment librpc/rpc/dcerpc.c: In function 'dcerpc_alter_context_send': librpc/rpc/dcerpc.c:1665: error: incompatible types in assignment The following command failed: x86_64-pc-linux-gnu-gcc -march=nocona -Os -mfpmath=sse -msse3 -pipe -g -DDEBUG_PASSWORD -DDEVELOPER -Wall -Wshadow -Werror-implicit-function-declaration -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wmissing-format-attribute -Wformat=2 -Wdeclaration-after-statement -Wunused-macros -Wno-format-y2k -Wno-unused-parameter -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -march=nocona -Os -mfpmath=sse -msse3 -pipe -g -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/ldb_tdb -Ilib/ldb/include -Ilib/ldb/include -Ilib/events -I../lib/tevent -Ilib/replace -march=nocona -Os -mfpmath=sse -msse3 -pipe -g -fPIC -I./include -I. -I./lib -I./../lib/replace -I./../lib/talloc -I./.. -D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H -c librpc/rpc/dcerpc.c -o librpc/rpc/dcerpc.o make: *** [librpc/rpc/dcerpc.o] Error 1
First of all, ebuild digest is deprecated by ebuild manifest. About the error, I think you forgot a make basics in the src_compile function. When I add that, I get this: In file included from auth/credentials/credentials_krb5.c:25: ./../lib/replace/system/kerberos.h:137:21: error: com_err.h: No such file or directory The following command failed: x86_64-pc-linux-gnu-gcc -O2 -pipe -march=core2 -g -DDEBUG_PASSWORD -DDEVELOPER -Wall -Wshadow -Werror-implicit-function-declaration -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wmissing-format-attribute -Wformat=2 -Wdeclaration-after-statement -Wunused-macros -Wno-format-y2k -Wno-unused-parameter -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/ldb_tdb -Ilib/ldb/include -Ilib/ldb/include -Ilib/events -I../lib/tevent -Ilib/replace -O2 -pipe -march=core2 -g -fPIC -I./include -I. -I./lib -I./../lib/replace -I./../lib/talloc -I./.. -D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H -c auth/credentials/credentials_krb5.c -o auth/credentials/credentials_krb5.o The file exists under source4/heimdal/lib/com_err/com_err.h, but I suppose using the external heimdal causes samba to ignore the bundled sources. Disabling external heimdal solves the issue and then the sources compile. I also think there should be a dependency on heimdal instead of just compiling against it if it's available. Since samba 4 doesn't support mit-krb5, I think we shouldn't depend on virtual/krb5 but instead directly on heimdal after the com_err.h problem is fixed. I checked and basics implies idl and proto targets. I don't know what the difference between idl and idl_full is, but I think idl is sufficient and therefore redundant. So your ebuild can be fixed by replacing idl_full with basics in the src_compile step. After it compiled, I tried to use the system tevent library, but it failed because it needs version 0.9.6 and 0.9.8 is the only version in portage or on ftp.samba.org. It seems we'll have to use the bundled version for now. When I came to the install step, it complained about installheaders. The correct target is installheader without the s. Thanks for the ebuild.
Created attachment 211130 [details] samba-libs-4.0.0_alpha8.ebuild > About the error, I think you forgot a make basics in the src_compile function. > When I add that, I get this: Thanks for pointing this out. Now I come > In file included from auth/credentials/credentials_krb5.c:25: > ./../lib/replace/system/kerberos.h:137:21: error: com_err.h: No such file or > directory > The file exists under source4/heimdal/lib/com_err/com_err.h, but I suppose > using the external heimdal causes samba to ignore the bundled sources. > Disabling external heimdal solves the issue and then the sources compile. com_err is part of sys-libs/e2fsprogs-libs. If you look at the samba-3 ebuilds you'll see, that they depend on it, too (I didn't know, why, so I left all "unknown" dependencies out at first.) So, if we depend on sys-libs/e2fsprogs-libs, and set the right -I directive in CPPFLAGS, it compiles. Anyway, there's another showstopper: Compiling auth/gensec/gensec_gssapi.c auth/gensec/gensec_gssapi.c: In function 'gensec_gssapi_start': auth/gensec/gensec_gssapi.c:174: error: 'GSS_C_DELEG_POLICY_FLAG' undeclared (first use in this function) auth/gensec/gensec_gssapi.c:174: error: (Each undeclared identifier is reported only once auth/gensec/gensec_gssapi.c:174: error: for each function it appears in.) The following command failed: x86_64-pc-linux-gnu-gcc -march=nocona -Os -mfpmath=sse -msse3 -pipe -g -DDEBUG_PASSWORD -DDEVELOPER -Wall -Wshadow -Werror-implicit-function-declaration -Wstrict-prototypes -Wpointer-arith -Wcast-qual -Wcast-align -Wwrite-strings -Wmissing-format-attribute -Wformat=2 -Wdeclaration-after-statement -Wunused-macros -Wno-format-y2k -Wno-unused-parameter -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/include -I/usr/include/et -march=nocona -Os -mfpmath=sse -msse3 -pipe -g -Ilib/ldb/include -Ilib/ldb/include -Ilib/ldb/ldb_tdb -Ilib/ldb/include -Ilib/ldb/include -Ilib/events -I../lib/tevent -Ilib/replace -I/usr/include/et -march=nocona -Os -mfpmath=sse -msse3 -pipe -g -fPIC -I./include -I. -I./lib -I./../lib/replace -I./../lib/talloc -I./.. -D_SAMBA_BUILD_=4 -DHAVE_CONFIG_H -I/usr/include/et -c auth/gensec/gensec_gssapi.c -o auth/gensec/gensec_gssapi.o make: *** [auth/gensec/gensec_gssapi.o] Error 1 A diff between my systems /usr/include/gssapi/gssapi.h and the included source4/heimdal/lib/gssapi/gssapi/gssapi.h shows that there are numerous differences between the two, leading to this error. Any ideas on how to get past this one? > I also think there should be a dependency on heimdal instead of just compiling > against it if it's available. Since samba 4 doesn't support mit-krb5, I think > we shouldn't depend on virtual/krb5 but instead directly on heimdal after the > com_err.h problem is fixed. Agreed. > I checked and basics implies idl and proto targets. I don't know what the > difference between idl and idl_full is, but I think idl is sufficient and > therefore redundant. So your ebuild can be fixed by replacing idl_full with > basics in the src_compile step. idl_full was an advice, Andrew Bartlett gave me once for the git sources. It generates all the idl code from the scratch. But I think, you're right: It doesn't do any good here. > After it compiled, I tried to use the system tevent library, but it failed > because it needs version 0.9.6 and 0.9.8 is the only version in portage or on > ftp.samba.org. It seems we'll have to use the bundled version for now. Yes, I figured that, too. > When I came to the install step, it complained about installheaders. The > correct target is installheader without the s. Fixed.
(In reply to comment #25) > In file included from auth/credentials/credentials_krb5.c:25: > ./../lib/replace/system/kerberos.h:137:21: error: com_err.h: No such file or > directory com_err.h resides in /usr/include/et while samba expects it in /usr/include Besides that, heimdal 1.2.x doesn't work since there are changes in the bundled version which haven't been included. 1.3.x might have those changes, but I can't find any confirmation about this. Therefore I propose to just use the bundled version for now (1.3.x hasn't even hit the tree yet) and focus on getting the server running. On http://github.com/webkiller71/samba4 I've made an overlay.
This might be the wrong place to ask, but since i read the word "franky" here and i am trying to set up such an installation: What is the purpose of the samba4 useflag in the in-tree samba3-lib/client/server packages? I thought it would build a franky setup, but it somehow does not, and/or it does not install the setup/provision files. (I am asking here, because #samba on freenode and the samba wiki was not really helpfull)
(In reply to comment #28) > This might be the wrong place to ask, but since i read the word "franky" here > and i am trying to set up such an installation: What is the purpose of the > samba4 useflag in the in-tree samba3-lib/client/server packages? I thought it > would build a franky setup, but it somehow does not, and/or it does not install > the setup/provision files. That is the idea. However, the current samba-server ebuilds do not actually build the samba4 binaries or setup/provision files. In my overlay I'm going to try and get this going as well. Torsten is also interested in getting franky going. My main problem with franky is that there currently very little documentation about getting it actually installed and working. Once I get the samba-server ebuild ready, I'll start playing with this and hopefully write some myself.
So we're a bit further and on http://wiki.github.com/webkiller71/samba4 I (very) briefly described the targets for the overlay. Inside the overlay we've tried to package samba 4 alpha 9, but we've run into the issue that we do not know which files belong in which package. Especially the bin files which I've listed for alpha 8 on http://wiki.github.com/webkiller71/samba4/samba-4-files. I'll update it later on with alpha 9 and try to split it into what's already in the ebuilds. Perhaps the samba herd can help us here. On my request tdb 1.2.0 was released since alpha 9 needs tdb >=1.1.7. I've bumped 1.1.5-r1 from the main tree and added it to my overlay. Secondly, Torsten did some great work on samba franky (the samba4 USE-flag for samba 3), but there are quite some issues with an external libtalloc. He filed some bugs and until they get resolved, there's not much we can do. Perhaps with samba 3.4.4 which is scheduled to be released soon.
As Andrew Bartlet told us on IRC: samba 3.4 contains a snapshot of samba 4 from some time ago and the franky support will never be more than a proof of concept. The git version is way further ahead and they can actually fix samba 4 issues there. That's why Torsten removed the samba-server-3.4 ebuild from the overlay. Torsten has been working on a git version, though I'm sure he can tell a lot more about that. On the samba 4 ebuilds, I noticed I forgot the provisioning scripts when I was actually going to try and get a samba 4 domain up and running. Adding those is simple, but then I noticed that the python modules aren't installed. I'm wondering if that's samba-libs or samba-server and how do do it, so I'll have some work.
(In reply to comment #31) Thanks, Ewoud, for stating our newest findings here. As for the git-ebuilds: I'm on a very tight working schedule at the moment, so I'm afraid they'll have to wait until next year. :-( If anyone wants to pick up the line where I had to leave it at present, a working ebuild for the latest git of samba3/Franky libs (net-fs/samba-libs-3.9999.ebuild) is to be found in Ewoud's git overlay (or my fork thereof). Merry Christmas everyone! See you next year, Torsten
Actually, you forgot to add net-fs/samba-libs-3.9999.ebuild before you committed. I now remember I forgot to add the init script which I'll most likely commit tomorrow. Since there's just one binary (/usr/sbin/samba), it's fairly trivial. It's also known that there are no docs in the alpha 10 tarbal and we don't install a smb.conf.example or something similar. I've added the python things to the libs and my very simple provisioning seemed to work. Since samba 4 doesn't listen on IPv6 and I currently just have an IPv6 only vserver to play with, I haven't really tested it out. Most likely it'll break horribly once you actually try to use it ;) If you do try it out, please report your findings. Basic steps to install: - add the overlay - add net-fs/samba{,-{libs,client,server}, sys-libs/{talloc,tevent,tdb} to your package.keywords - emerge samba - Define your realm and workgroup under global and add the netlogon and sysvol shares to smb.conf - Read http://wiki.samba.org/index.php/Samba4/HOWTO starting from step 4 - Use /usr/share/samba/setup/provision - Hope I've added the init script already - Break your computer / have a samba 4 domain
(In reply to comment #33) > Actually, you forgot to add net-fs/samba-libs-3.9999.ebuild before you > committed. I've done that now. Have fun... :-)
(In reply to comment #34) > (In reply to comment #33) > > Actually, you forgot to add net-fs/samba-libs-3.9999.ebuild before you > > committed. > I've done that now. Have fun... :-) I've merged your branch so it should be in mine as well. I've also added the init script so we should be able to get a basic samba server going. Note that we still haven't assigned more files to ebuilds so you might miss tools. If you do, please have a look at http://wiki.github.com/webkiller71/samba4/samba-4-files and see if you can place them. smbtorture doesn't currently build with a system libtalloc due to a missing function.
I've bumped to alpha 11 and cleaned up alpha 10. Alpha 11 is a single ebuild again since the split ebuilds overlap so much, it's hardly worth the effort. It's now done using USE-flags. We still have to assign the files which are listed on http://wiki.github.com/webkiller71/samba4/samba-4-files.
(In reply to comment #33) > If you do try it out, please report your findings. alpha11 only builds with server AND client useflag! When i tried the server useflag alone i got: Compiling lib/ldb/tools/cmdline.c In file included from lib/ldb/tools/cmdline.c:37: ./dsdb/common/proto.h:218: warning: 'struct repsFromToBlob' declared inside parameter list ./dsdb/common/proto.h:218: warning: its scope is only this definition or declaration, which is probably not what you want ./dsdb/common/proto.h:220: warning: 'struct repsFromToBlob' declared inside parameter list ./dsdb/common/proto.h:224: warning: 'struct drsuapi_DsReplicaCursor2' declared inside parameter list ./dsdb/common/proto.h:226: warning: 'struct drsuapi_DsReplicaCursor' declared inside parameter list ./dsdb/common/proto.h:279: warning: 'struct dsdb_schema' declared inside parameter list ./dsdb/common/proto.h:279: warning: 'struct dsdb_attribute' declared inside parameter list ./dsdb/common/proto.h:285: warning: 'struct dsdb_schema' declared inside parameter list ./dsdb/common/proto.h:285: warning: 'struct dsdb_attribute' declared inside parameter list Partially linking bin/mergedobj/ldb_cmdline.o Linking bin/ldbedit collect2: ld returned 1 exit status make: *** [bin/ldbedit] Error 1 * ERROR: net-fs/samba-4.0.0_alpha11 failed: * emake BINPROGS failed > Basic steps to install: > - add the overlay > - add net-fs/samba{,-{libs,client,server}, sys-libs/{talloc,tevent,tdb} to your > package.keywords > - emerge samba Done that! > - Define your realm and workgroup under global and add the netlogon and sysvol > shares to smb.conf Didn't do that, I thought the provisioning creates a smb.conf? If I need to use a smb.conf, can you provide a working minimal sample, please? > - Read http://wiki.samba.org/index.php/Samba4/HOWTO starting from step 4 tried that, didnt work > - Use /usr/share/samba/setup/provision It is /etc/samba/setup/provision with alpha11 > - Hope I've added the init script already Seems so > - Break your computer / have a samba 4 domain Nope, didnt work (none of the above :) Since using explicit options didnt work, I tried this (leads to the same error as with explicit options!) host samba # setup/provision --interactive Realm [DOMAIN.TLD]: Domain [DOMAIN]: Server Role (dc, member, standalone) [dc]: Administrator password: Traceback (most recent call last): File "setup/provision", line 192, in <module> ldap_backend_type=opts.ldap_backend_type) TypeError: provision() got an unexpected keyword argument 'nogroup' I don't quiete get it... BTW, do you have an irc channel where you hang out? I am on freenode with the same nick as here. Installed versions: 4.0.0_alpha11!m[1](10:41:59 02.02.2010)(client netapi python server threads tools -caps -debug -dso -gnutls -sqlite)
(In reply to comment #37) > > - Use /usr/share/samba/setup/provision > It is /etc/samba/setup/provision with alpha11 Ok, we were both wrong! /etc/samba/setup on my system was a leftover from october and some fiddling around with franky! But alpha11 installs the setup stuff in /usr/share/setup (found it while using equery -f samba). Seems as if MY_PN does not work. Patch: sed -i 's|/usr/share/${MY_PN}|/usr/share/samba|g' samba-4.0.0_alpha11.ebuild So this error was only caused by my old, faulty provision file!!! > Traceback (most recent call last): > File "setup/provision", line 192, in <module> > ldap_backend_type=opts.ldap_backend_type) > TypeError: provision() got an unexpected keyword argument 'nogroup' It did provision properly now, on with the b0rkage!!!
(In reply to comment #37) > alpha11 only builds with server AND client useflag! I'll look into this. > I don't quiete get it... BTW, do you have an irc channel where you hang out? I > am on freenode with the same nick as here. Not really, we've done most in queries. I'm creating #gentoo-samba now so if you have any more questions.. (In reply to comment #38) > (In reply to comment #37) > > > - Use /usr/share/samba/setup/provision > > It is /etc/samba/setup/provision with alpha11 > Ok, we were both wrong! > /etc/samba/setup on my system was a leftover from october and some fiddling > around with franky! > But alpha11 installs the setup stuff in /usr/share/setup (found it while using > equery -f samba). Seems as if MY_PN does not work. > > Patch: > sed -i 's|/usr/share/${MY_PN}|/usr/share/samba|g' samba-4.0.0_alpha11.ebuild I've replaced ${MY_PN} with ${PN}. ${MY_PN} is a leftover from the split ebuilds. Thanks for reporting. > It did provision properly now, on with the b0rkage!!! Good. I'm interested in your findings. If you miss any binaries, please report (and if they should be client, server or both).
Good news everyone! ;) + 23 Feb 2010; Patrick Lauer <patrick@gentoo.org> + +samba-4.0.0_alpha11.ebuild: + Adding masked samba4 alpha. Thanks to ewoud and the other people in + #195703
It seems samba-4 and samba-libs can't be installed at the same time. But GVFS depends on Samba and is cruical in a corporated environment as is libmapi (for Exchange 2007). So how to install libmapi (samba-4) and GVFS with samba (samba-libs) at the same time?
We could try to slot them. There will be some file collisions and of course you couldn't run both servers at the same time (perhaps you could take great care about about the IPs you listen to). I expect the main issue will be binaries that collide. For example smbclient, ldb*, smbstatus. That could be solved by renaming (smbclient4, smbstatus4) or blockers (in samba 4: tools? ( !net-fs/samba:0[ldb] )). I expect the server parts and libraries hardly collide. Samba 4 client utils aren't very usable imho so you won't gain much by using them so a block could be used as well. For ldb having a separate package would be the better solution, but there's no release yet. Debian solves this by extracting ldb from the samba tree. I don't know if this is a viable solution for us. The true solution would of course be samba franky, but that's still experimental (which is why the samba 4 USE-flag was removed from samba 3.4.6 and 3.5.0). In other news, it seems they're getting close to merging their heimdal patches upstream so the internal copy of heimdal might not be needed anymore with the next samba 4 alpha.
Little heads up: samba 4 master has switched to the waf build system. I haven't found an easy way to split it up into server and client utils, besides perhaps simply removing binaries. On the upside, the build size is down from sometimes >2GB to <100MB. It should also be better suited for parralel builds. See http://wiki.samba.org/index.php/Waf for more information. They also removed mount.cifs and friends since it's now part of the cifs-utils package (see #308655). I expect we'll see the same in samba 3.6 (or later).
When will samba-4.0.0_alpha13 in portage tree? I really need it because I want to compile net-libs/libmapi.
Due to the WAF buildsystem changes, it's not very easy. For some reason there are many assumptions that it can merge straight to the filesystem. I'm trying to look into it, but due to a lack of time this might take some time.
Disclaimer: I never actually used samba 4 and since I no longer maintain any windows machines, the chance of actually using it has decreased dramatically. This means that it's hardly tested. In my overlay there's a somewhat untested samba-4.0.0_alpha13 and updated 4.9999. It compiles and I could provision with it, but haven't actually joined the domain yet. There's also the issue that alpha 13 depends on unreleased versions of tdb and talloc so it uses bundled versions instead of system versions. So for those who dare, see http://github.com/webkiller71/samba4. There's http://github.com/webkiller71/samba4/blob/master/overlay.xml for layman users. Last, I haven't really looked into slotting, but patches welcome. Other suggestions are also highly welcome.
(In reply to comment #46) > So for those who dare, see http://github.com/webkiller71/samba4. There's > http://github.com/webkiller71/samba4/blob/master/overlay.xml for layman users. There seem to be something wrong with the git files. I try to access with http/https both tell me that this git files don't exists anymore... Please check * samba4 [Git ] (git://github.com/webkiller71/samba4.git ) dcmwaisrv2 ~ # layman -s samba4 * Running... # ( cd /var/lib/layman/samba4 && /usr/bin/git pull ) Already up-to-date. * * Success: * ------ * * Successfully synchronized overlay "samba4". * * Warnings: * ------ * * Overlay "samba4" could not be found in the remote lists. * Please check if it has been renamed and re-add if necessary. *
Adding the overlay worked with this command for me: layman -o https://github.com/webkiller71/samba4/raw/master/overlay.xml -f -a samba4 but 4.9999 fails to configure atm, alpha13 configures fine but fails to build...
I just changed overlay.xml to reflect githubs https-only policy. Also, since I don't really follow 4.9999, it can break and I wonder if I even should offer it at all. I'll look into this when I have time. I am interested in knowing why alpha 13 fails. Do you have any error message?
'configure' finished successfully (1m15.039s) >>> Source configured. >>> Compiling source in /var/tmp/portage/net-fs/samba-4.0.0_alpha13/work/samba-4.0.0alpha13/source4 ... WAF_MAKE=1 ../buildtools/bin/waf build make: *** [all] Segmentation fault I don't quiet get why this is happening. It only happens when I use this ebuild, manually using the tarball works. Also, this is the only ebuild which fails and it only fails on this special machine... I just checked on the laptop, building there works fine. So probably it is this system/hardware which is faulty, not the ebuild. The error for 4.9999 is: Checking for system pytalloc-util >= 2.0.4 : not found ERROR: System library pytalloc-util of version 2.0.4 not found, and bundling disabled * ERROR: net-fs/samba-4.9999 failed: * configure failed Happening on both machines and possibly only a DEPEND issue. Although sys-libs/talloc is only avaiable in version 2.0.1 in the official portage tree.
The problem with the 4.0.0_alpha13 version was caused by grsec disagreeing with pythons overstepping of rescource limits... as @blueness on #gentoo-hardened adviced I upgraded my python version to ~2.6.6 and the ebuild worked flawlessly! So the problem was indeed my hardened system runnning hardened-sources with grsec restrictions. I didn't dig further into the 4.9999 issues, since I am happy with alpha13
*** Bug 371599 has been marked as a duplicate of this bug. ***
For the record, I moved my github account so the new URL is https://github.com/ekohl/samba4 but nothing has changed.
Created attachment 277089 [details] net-fs/samba-4.0.0_alpha14 ebuild Samba alpha 14 ebuild for use with libmapi-0.10 using built in ldb, and system tdb, talloc and tevent The ebuild removes a conflicting _tevent.so file (conflicting with system tevent), and adds a symlink for libldb.so, so that libmapi can link correctly.
Created attachment 288603 [details] ebuild for samba-4.0.0_alpha17 modified alpha14 ebuild, had to adjust S= to get it to work. compiles fine on my ~amd64 system.
I've bumped to alpha 17 in my overlay. It now uses the waf-utils eclass. Again with the warning that samba 4 is alpha, but my ebuilds haven't seen extensive testing either.
The alpha 17-r2 version in my overlay should now properly work. Waiting for ldb-1.1.2 to be released so I can use system packages only instead of the bundled ldb. It could use more review though. There are also many more configure options, but I don't know if they're all useful to expose. Some of them are currently exposed in samba 3, so it might be useful.
I get lots of these: [2563/2678] Linking default/source3/auth/libauth-script.so [2564/2678] Linking default/source3/libsmbd_base.so default/source3/printing/print_cups_89.o: In function `cups_connect': print_cups.c:(.text+0xb7): undefined reference to `cupsServer' print_cups.c:(.text+0x12f): undefined reference to `httpConnect' print_cups.c:(.text+0x219): undefined reference to `ippPort' default/source3/printing/print_cups_89.o: In function `cups_job_submit': print_cups.c:(.text+0x319): undefined reference to `cupsSetPasswordCB' print_cups.c:(.text+0x332): undefined reference to `ippNew' print_cups.c:(.text+0x348): undefined reference to `cupsLangDefault' print_cups.c:(.text+0x36e): undefined reference to `ippAddString' print_cups.c:(.text+0x38f): undefined reference to `ippAddString' print_cups.c:(.text+0x3cf): undefined reference to `cupsLangFree' print_cups.c:(.text+0x3dc): undefined reference to `httpClose' print_cups.c:(.text+0x494): undefined reference to `ippAddString' print_cups.c:(.text+0x4db): undefined reference to `ippAddString' print_cups.c:(.text+0x503): undefined reference to `ippAddString' print_cups.c:(.text+0x59d): undefined reference to `ippAddString' print_cups.c:(.text+0x5dc): undefined reference to `cupsParseOptions' print_cups.c:(.text+0x63f): undefined reference to `cupsDoFileRequest' print_cups.c:(.text+0x678): undefined reference to `ippDelete' print_cups.c:(.text+0x6b0): undefined reference to `cupsEncodeOptions' print_cups.c:(.text+0x727): undefined reference to `cupsLastError' print_cups.c:(.text+0x72e): undefined reference to `ippErrorString' print_cups.c:(.text+0x766): undefined reference to `ippFindAttribute' print_cups.c:(.text+0x7f6): undefined reference to `cupsLastError' print_cups.c:(.text+0x7fd): undefined reference to `ippErrorString' default/source3/printing/print_cups_89.o: In function `cups_job_resume': print_cups.c:(.text+0x90b): undefined reference to `cupsSetPasswordCB' print_cups.c:(.text+0x924): undefined reference to `ippNew' print_cups.c:(.text+0x93a): undefined reference to `cupsLangDefault' print_cups.c:(.text+0x960): undefined reference to `ippAddString' print_cups.c:(.text+0x980): undefined reference to `ippAddString' print_cups.c:(.text+0x9d0): undefined reference to `ippAddString' print_cups.c:(.text+0xa06): undefined reference to `cupsLangFree' print_cups.c:(.text+0xa13): undefined reference to `httpClose' print_cups.c:(.text+0xa9d): undefined reference to `ippAddString' print_cups.c:(.text+0xaaf): undefined reference to `cupsDoRequest' print_cups.c:(.text+0xae2): undefined reference to `ippDelete' print_cups.c:(.text+0xb1d): undefined reference to `cupsLastError' print_cups.c:(.text+0xb24): undefined reference to `ippErrorString' print_cups.c:(.text+0xba5): undefined reference to `cupsLastError' print_cups.c:(.text+0xbac): undefined reference to `ippErrorString' [...] The previous alphas (since 11) compiled flawless. Cups is installed: Installed versions: 1.4.8-r1!t(13:52:53 04.09.2011)(acl dbus jpeg kerberos ldap linguas_de perl png python samba ssl threads tiff -X -debug -elibc_FreeBSD -gnutls -java -linguas_da -linguas_es -linguas_eu -linguas_fi -linguas_fr -linguas_id -linguas_it -linguas_ja -linguas_ko -linguas_nl -linguas_no -linguas_pl -linguas_pt -linguas_pt_BR -linguas_ru -linguas_sv -linguas_zh -linguas_zh_TW -pam -php -slp -static-libs -xinetd) Any ideas?
(In reply to comment #58) > I get lots of these: > [2563/2678] Linking default/source3/auth/libauth-script.so > [2564/2678] Linking default/source3/libsmbd_base.so > default/source3/printing/print_cups_89.o: In function `cups_connect': > print_cups.c:(.text+0xb7): undefined reference to `cupsServer' > [...] > Any ideas? This was related to some libgssapi.so.2 issues on my system which just got solved by a revdep-rebuild, sorry for the noise. All seems well now!
Created attachment 290877 [details] Samba 4 alpha 17 Attached is the newest version from my overlay. I feel that it's in better shape than alpha 11 and would like to ask a gentoo dev to push it to the tree. It should also obsolete all already attached files, but I have no permission to do so.
Created attachment 290879 [details, diff] Patch as used in samba-4.0.0alpha17-r2.ebuild This patch adds the missing dependency on com_err. It's already upstream so should be in included in alpha 18.
Created attachment 291475 [details, diff] samba-4.0.0alpha17.ebuild samba-4.0.0_alpha17 in portage, based in the ebuild provided by Ewoud Kohl van Wijngaarden. I'm sure some dependencies and options are missing, but now we have a waf samba ebuild in portage to play with :) + 01 Nov 2011; Víctor Ostorga <vostorga@gentoo.org> +files/4.0/com_err.patch, + +files/4.0/samba4.initd, +samba-4.0.0_alpha17.ebuild: + Updating samba 4, based in work of Ewoud Kohl van Wijngaarden + <gentoo@kohlvanwijngaarden.nl> et all in bug 195703
I'm afraid I did notice a blocking issue. First of all I'm placing the modules in the wrong place. Second it seems the .so files in the python dir are not executable. I'm working on an -r3, but currently it fails.
(In reply to comment #63) > I'm afraid I did notice a blocking issue. First of all I'm placing the modules > in the wrong place. Second it seems the .so files in the python dir are not > executable. I'm working on an -r3, but currently it fails. I didn't understand what you are referring to. With modules do you mean python_mod stuff? If you have build problems please attach your build.log
Created attachment 291521 [details, diff] Patch to fix some issues in alpha17 This patch places the samba modules in /usr/$(get_libdir)/samba (like Debian does) and makes all .so files executable (copied from Fedora's spec file). Note that to actually provision you still need an ugly hack: LD_LIBRARY_PATH="/usr/lib/samba" provision How to solve that one is an open issue that I'm not sure on how to solve and somewhat limited on time atm.
to fix your LD_LIBRARY_PATH you just need to add a script to the profile.d dir ie add a file to the files dir for the ebuild like samba.sh and have include this: export LD_LIBRARY_PATH="/usr/lib/samba" then add the following line to src_install: cp "${FILESDIR}"/samba.sh /etc/profile.d/
(In reply to comment #66) > to fix your LD_LIBRARY_PATH you just need to add a script to the profile.d dir Or, even better, add sth. like /etc/env.d/99samba: LD_LIBRARY_PATH="/usr/lib/samba" First of all, that's the way, global environment variables are set in Gentoo (/etc/env.d/* is processed into /etc/profile.env, which is in turn included with /etc/profile). Secondly, that way LD_LIBRARY_PATH gets accumulated correctly, in case you set other important values for that variable elsewhere in /etc/env.d. Torsten
Ewoud, thanks for all the work! > This patch places the samba modules in /usr/$(get_libdir)/samba (like Debian > does) and makes all .so files executable (copied from Fedora's spec file). Just a small remark: There's a typo in your ebuild. Instead of --with-modulesdir=/usr/$(get_libdir) it has --with-modulesdir=/usr/lib/$(get_libdir) Best, Torsten
(In reply to comment #68) > Just a small remark: There's a typo in your ebuild. > > Instead of --with-modulesdir=/usr/$(get_libdir) > it has --with-modulesdir=/usr/lib/$(get_libdir) Great catch, thanks. Unfortunately this still doesn't fix the the problem that /usr/lib/python2.7/site-packages/samba/_ldb.so can't find /usr/lib/samba/liberrors.so and I lack the time and knowledge to fix this. Maybe someone could look into this and tell if it's in the packaging or the code.
Created attachment 300533 [details, diff] samba-4.0.0_alpha17.ebuild.patch (In reply to comment #69) > Unfortunately this still doesn't fix the the problem that > /usr/lib/python2.7/site-packages/samba/_ldb.so can't find > /usr/lib/samba/liberrors.so and I lack the time and knowledge to fix this. > Maybe someone could look into this and tell if it's in the packaging or the > code. The attached patch to your latest ebuild should do the trick. Also, it sanitizes the KEYWORDS variable, which should normally be left empty for live ebuilds. Thus, you can enable or disable the live package by =net-fs/samba-4.9999 ** in /etc/portage/package.keywords Best, Torsten
(In reply to comment #70) > Created attachment 300533 [details, diff] [details, diff] > samba-4.0.0_alpha17.ebuild.patch > > (In reply to comment #69) > > Unfortunately this still doesn't fix the the problem that > > /usr/lib/python2.7/site-packages/samba/_ldb.so can't find > > /usr/lib/samba/liberrors.so and I lack the time and knowledge to fix this. > > Maybe someone could look into this and tell if it's in the packaging or the > > code. > > The attached patch to your latest ebuild should do the trick. From a discussion I'm having on IRC with ssuominen I discovered that file /usr/lib64/samba/libsamba_python.so isn't installed with the correct rpath and thus fail. With his pointers I think I can find out why it fails and remove the need for the ugly LDPATH workaround. > Also, it sanitizes the KEYWORDS variable, which should normally be left empty > for live ebuilds. Thus, you can enable or disable the live package by > > =net-fs/samba-4.9999 ** > > in /etc/portage/package.keywords Great suggestion.
Nice to see all this work on the ebuild being done! I am afraid to get spanked for being a spammer, but I made this wiki entry a while ago and I think some of you might find it useful: http://en.gentoo-wiki.com/wiki/Samba4_as_Active_Directory_Server The upstream wiki entry is a mix of being outdated, underinforming and generally being only for the ones who already know what to do, so I cloned it and added various other informations. Most of the stuff I really tried and tested myself. What I am looking for atm is information on how to make use of swat (again). Just starting /usr/sbin/swat doesn't really help and I am not seein an example swat.conf.
Since I have a few days off I had some time to spend on samba. I've added alpha17-r5 in my overlay with some patches to the build system that should remove any need for ugly LDPATH hacks. If someone could confirm this solves their issues it'd be lovely.
(In reply to comment #73) > Since I have a few days off I had some time to spend on samba. I've added > alpha17-r5 in my overlay with some patches to the build system that should > remove any need for ugly LDPATH hacks. If someone could confirm this solves > their issues it'd be lovely. Hi Ewoud, thanks for the fixes. I incorporated them in my (as of yet) private samba-4.9999.ebuild and everything seems to work now without tweaking LD_LIBRARY_PATH. Good job! Have some nice days off! Torsten
Created attachment 303463 [details] samba-4.0.0_alpha18.ebuild Ebuild for Samba-4.0.0alpha18 (released 2012-02-25). Should include all of Ewouds latest fixes - and some of my own. ;-)
Created attachment 303465 [details, diff] samba-4.0.0_alpha18-missing-dependencies.patch Patch to go into $FILESDIR.
Created attachment 303467 [details] samba4.initd Init script for samba 4.
(In reply to comment #75) PS: The ebuild is based on system libs of heimdal, ldb, talloc, tdb and tevent, so it should be well prepared for the main tree. :-)
I've had a look at alpha 18 and didn't find as many dependencies yet. Have you had a chance to talk with upstream to accept the patches?
(In reply to comment #79) > I've had a look at alpha 18 and didn't find as many dependencies yet. Have you > had a chance to talk with upstream to accept the patches? Honestly: I didn't try as of yet. Anyway, according to Andrew Bartlett, Alpah19 will be much more distribution friendly, since they are in the process of sorting out the tdb vs. tdb2 problems. Perhaps this would be a good opportunity to get the dependency patches upstream...
I've been getting: [2911/3165] Linking default/source3/smbd/smbd /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: default/source4/heimdal/kuser/kgetcred_7.o: undefined reference to symbol 'free_Ticket@@HEIMDAL_ASN1_1.0' /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'free_Ticket@@HEIMDAL_ASN1_1.0' is defined in DSO /usr/lib64/libasn1.so.8 so try adding it to the linker command line /usr/lib64/libasn1.so.8: could not read symbols: Invalid operation collect2: ld returned 1 exit status Waf: Leaving directory `/var/tmp/portage/net-fs/samba-4.0.0_alpha18/work/samba-4.0.0alpha18/bin' Build failed: -> task failed (err #1): {task: cc_link print_version_2.o,version_2.o,kgetcred_7.o -> samba4kgetcred} both with Torsten's ebuilds and with Ewoud's overlay. Any suggestions?
(In reply to comment #81) > I've been getting: > > [2911/3165] Linking default/source3/smbd/smbd > /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ > ld: default/source4/heimdal/kuser/kgetcred_7.o: undefined reference to > symbol 'free_Ticket@@HEIMDAL_ASN1_1.0' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../../x86_64-pc-linux-gnu/bin/ > ld: note: 'free_Ticket@@HEIMDAL_ASN1_1.0' is defined in DSO > /usr/lib64/libasn1.so.8 so try adding it to the linker command line > /usr/lib64/libasn1.so.8: could not read symbols: Invalid operation > collect2: ld returned 1 exit status > Waf: Leaving directory > `/var/tmp/portage/net-fs/samba-4.0.0_alpha18/work/samba-4.0.0alpha18/bin' > Build failed: -> task failed (err #1): > {task: cc_link print_version_2.o,version_2.o,kgetcred_7.o -> > samba4kgetcred} > > both with Torsten's ebuilds and with Ewoud's overlay. Any suggestions? Which version of heimdal are you using?
Created attachment 312565 [details] samba-4.0.0_alpha20.ebuild New ebuild for samba-4.0.0_alpha20. Depends on sys-libs/tdb-1.2.10 (#416957) and sys-libs/ldb-1.1.6 (#414113). I worked with Jelmer Vernoij to get rid of the Python lib dependency problems, but we did not find a proper solution as of yet. Thus, a subset of the dependency patch is still needed. (I will upload in a minute. :-) Best, Torsten
Created attachment 312567 [details, diff] samba-4.0.0_alpha20-private-dependencies.patch The aforementioned patch.
Checking for system tdb >= 2.0.0 : not found ERROR: System library tdb of version 2.0.0 not found, and bundling disabled * ERROR: net-fs/samba-4.0.0_beta1 failed (configure phase): the beta1 is currently in a really silly state, let's see if tdb can be fixed ...
(In reply to comment #85) > Checking for system tdb >= 2.0.0 > : not found > [...] > the beta1 is currently in a really silly state, let's see if tdb can be > fixed ... Yes, that problem exists even in alpha20/21, and even when the --disable-tdb2 switch is given. :-(
Checking for system tdb >= 1.2.9 : yes ERROR: Python module pytdb of version 1.2.9 not found, and bundling disabled This is from the alpha18 ebuild and I dare say that somebody introduced this problem with some patch or whatever. About half a year ago the alpha18 ebuild was working really nice, then somebody introduced /usr/sbin/samba_spnupdate: ImportError: libtdb_compat.so: cannot open shared object file: No such file or directory and after that, the above tdb check started to fail when recompiling. So, during the last year, all alpha builds worked fine, whatever the mode of installation was (bundled vs system libs). Then some change was done and since then the package is gimped. I'll try the alpha20 ebuilds now.
> This is from the alpha18 ebuild and I dare say that somebody introduced this > problem with some patch or whatever. About half a year ago the alpha18 > ebuild was working really nice, then somebody introduced > /usr/sbin/samba_spnupdate: ImportError: libtdb_compat.so: cannot open shared > object file: No such file or directory I suspect tdb itself being the problem. I'd suggest to wait until the tdb problems are sorted out by the Samba team, and then giving betaX a shot. The Samba folks ar in the process of renaming tdb2 to ntdb and then releasing that as a new package. Otherwise, you should check, whether your sys-libs/tdb is build with the "python" USE-flag.
It started to fail with later alpha17 releases and now with alpha20 I still see [2012/06/12 15:33:50, 0] ../lib/util/util_runcmd.c:334(samba_runcmd_io_handler) /usr/sbin/samba_spnupdate: ImportError: libtdb_compat.so: cannot open shared object file: No such file or directory although I do have two of them on my system: equery b libtdb_compat.so * Searching for libtdb_compat.so ... net-fs/samba-4.0.0_alpha20 (/usr/lib64/samba/libtdb_compat.so) sys-libs/ldb-1.1.6 (/usr/lib64/ldb/libtdb_compat.so) Also I doubt that my systems tdb is really the culprit (or maybe it is, if earlier aplha17 ebuild versions were using bundled libs) since genlop says this: Mon Sep 13 11:35:52 2010 >>> sys-libs/tdb-1.2.1-r1 merge time: 57 seconds. Mon Jul 11 11:08:54 2011 >>> sys-libs/tdb-1.2.9 merge time: 1 minute and 8 seconds. Wed May 16 22:46:58 2012 >>> sys-libs/tdb-1.2.10 merge time: 1 minute and 47 seconds. And it did work fine after July 2011. It stopped working all that well around christmas or so and after I switched from homebrew ebuild to samba4 overlay. Samba4 overlay worked fine for a while and then b0rked.
(In reply to comment #89) > * Searching for libtdb_compat.so ... > net-fs/samba-4.0.0_alpha20 (/usr/lib64/samba/libtdb_compat.so) This one shouldn't be there. It's from a bundled library. Anyway, the samba4 overlay is regarded highly experimental and not maintained by a Gentoo developer, so you should expect things to fail. Does the alpha20 attached to this bug report earlier work for you?
(In reply to comment #90) > (In reply to comment #89) > > * Searching for libtdb_compat.so ... > > net-fs/samba-4.0.0_alpha20 (/usr/lib64/samba/libtdb_compat.so) > > This one shouldn't be there. It's from a bundled library. The thing is, that I do not understand why it is on my system AND isn't found by the samba server. As you say, either everything is bundled OR from the system. > Anyway, the samba4 overlay is regarded highly experimental and not > maintained by a Gentoo developer, so you should expect things to fail. There is no alpha20 in the overlay, as far as i can see. > Does the alpha20 attached to this bug report earlier work for you? I use the alpha20 ebuild from this very bugreport with these useflags: Installed versions: 4.0.0_alpha20!m[?](14:20:31 12.06.2012)(acl addns ads avahi client cups ldap swat winbind -aio -cluster -debug -fulltest -gnutls -iprint -pam -quota -syslog) I did not do a fresh provision but used all configs I used from my working alpha17 stage. Basically doing everything that is described here: http://en.gentoo-wiki.com/wiki/Samba4_as_Active_Directory_Server (I am the author of that article, so thats pretty much a description of my personal setup) Most things are working as expected: File shares, logging into Win machines with domain users, kinit from various machines as domain user. I will need to test further things when I have libvirtd behaving fine again, especially the rest of my gssapi/sasl/kerberos services.
(In reply to comment #91) > > > net-fs/samba-4.0.0_alpha20 (/usr/lib64/samba/libtdb_compat.so) > > > > This one shouldn't be there. It's from a bundled library. > The thing is, that I do not understand why it is on my system AND isn't > found by the samba server. As you say, either everything is bundled OR from > the system. First of all: No, I didn't say that. You can choose during configure, which libraries you want to have bundled and which not. What you are most probably facing, is another issue: The default location for all Samba 4 related stuff is in /usr/local. So, by creating a Gentoo-conform ebuild, we moved paths around a lot to place everything in the appropriate locations in /usr. So, none of the Python stuff bundled with Samba4 (all provisioning is done in Python) expects libraries to be in /usr/lib64/samba. I tried to fix that with the patch I attached, but according to Jelmer Vernoij of the Samba-Team, that is the wrong approach. There's something wrong with Samba 4's build system, so some things break as soon as you change the standard installation paths. You can circumvent the matter by prepending: LD_LIBRARY_PATH="/usr/lib64/samba:${LD_LIBRARY_PATH}" to whatever command fails for you. I filed a bug report with Samba: https://bugzilla.samba.org/show_bug.cgi?id=8796 > > Anyway, the samba4 overlay is regarded highly experimental and not > > maintained by a Gentoo developer, so you should expect things to fail. > There is no alpha20 in the overlay, as far as i can see. That's why I attached one here a while ago. :-) > Most things are working as expected: File shares, logging into Win machines > with domain users, kinit from various machines as domain user. I will need > to test further things when I have libvirtd behaving fine again, especially > the rest of my gssapi/sasl/kerberos services. Please keep in mind that I'm not an official Gentoo developer. The ebuild I attached works for me (and, obviously, for you), so it could be taken as a template by one of the official devs. However, with beta2 coming within the next two weeks, I highly doubt that another alpha makes it to portage. Best, Torsten
I decided to start working packaging beta 1 and ran into the same dependency issues. I'll see if I can write some patches to fix it.
I did a lot of cleanup lately, so there is now a working ebuild for samba-4.0.0beta3 in my overlay at https://github.com/tkurbad/samba4 Be aware, however, that - for the time being - we are forced to use the bundled ldb library. This means that for this ebuild to work on your Samba 4 system, there MUSN'T be any packages that depend on sys-libs/ldb! According to the Samba team, ldb-1.1.7 will be released soon, but all developers who could do so are on vacation, ill or otherwise prevented. That said, happy testing everybody. :-) Best, Torsten
I looked at your ebuild and repoman complained about the missing tevent 0.9.16 but I can compile with 0.9.15. I think because you used --bundled-libraries=ldb without NONE, so it falls back to bundled libraries. Seems we have to file a bug to get it bumped.
(In reply to comment #95) > I looked at your ebuild and repoman complained about the missing tevent > 0.9.16 but I can compile with 0.9.15. I think because you used > --bundled-libraries=ldb without NONE, so it falls back to bundled libraries. > Seems we have to file a bug to get it bumped. Ewoud, see Bug #424705 :-) Best, Torsten
Ah, it just hasn't hit the mirrors yet. I even looked on packages.gentoo.org and looked for tevent bugs, but failed because it was already closed. I'll add NONE to --bundled-libraries and once it passed repoman and builds I'll push beta 3 to my overlay. Thanks for doing the heavy lifting :)
(In reply to comment #97) > I'll add NONE to --bundled-libraries and once it passed repoman and builds I'll > push beta 3 to my overlay. The problem is that we need the bundled ldb for now. Andrew Tridgell, who could do the release bump of ldb to 1.1.7 is seriously ill atm. But the guys on #samba-technical promised, that someone will take care of the matter within a few days. Nonetheless, I'm very confident that we could see another samba 4 in the regular portage tree as soon as Beta 4 is out (in ca. 2 weeks). The library issues should be resolved by then. That way, we'd most certainly reach a wider audience. Thanks for bearing with me! Torsten
By adding(In reply to comment #98) > (In reply to comment #97) > > I'll add NONE to --bundled-libraries and once it passed repoman and builds I'll > > push beta 3 to my overlay. > > The problem is that we need the bundled ldb for now. By adding I meant make it ldb,NONE. > Andrew Tridgell, who could do the release bump of ldb to 1.1.7 is seriously > ill atm. But the guys on #samba-technical promised, that someone will take > care of the matter within a few days. That sounds bad. Hope he'll be ok. > Nonetheless, I'm very confident that we could see another samba 4 in the > regular portage tree as soon as Beta 4 is out (in ca. 2 weeks). The library > issues should be resolved by then. That way, we'd most certainly reach a > wider audience. That's good to hear.
(In reply to comment #99) > By adding I meant make it ldb,NONE. Ah, got you wrong here. You'll need to add pyldb-util,NONE to the line to make it work. I pushed that change to my overlay right now. > That sounds bad. Hope he'll be ok. I hope so, too. He also couldn't attend Samba XP in May. :-(
sys-libs/ldb-1.1.8 has been released (s. bug #425488). I've updated the beta3 ebuild in my overlay accordingly. It now builds using the system library (while ldb-1.1.8 still comes from my local overlay, but will be in portage soon, I hope). Happy testing!
*** Bug 428380 has been marked as a duplicate of this bug. ***
Created attachment 321354 [details] samba-4.0.0_beta6.ebuild verbump, some tweaks
Created attachment 321378 [details] samba-4.0.0_beta6-r1.ebuild Updated ebuild, essentially just a renamed version from Torsten's overlay. Note that this has an RDEPEND on iniparser, but iniparser does not install a pkg-config file, so the samba configure script does not detect it is installed and uses its internal copy.
There's now an ebuild for samba-4.0.0_rc1 in my overlay. It depends on new versions of tevent and ldb, which I already filed bugs for. These are in my overlay, too, until they get bumped in the tree. Have fun, Torsten PS: There are still some issues going on, so the ebuild might change once in a while. I'll try to remember to bump revisions, though... :-)
> PS: There are still some issues going on, so the ebuild might change once in > a while. I'll try to remember to bump revisions, though... :-) The ebuild should be fixed now.
Torsten Kurbad, tdb2 required or optional for samba4 ?
(In reply to comment #107) > Torsten Kurbad, tdb2 required or optional for samba4 ? tdb2 (=ntdb) is optional. In my ebuild, I invoke 'configure' with '--disable-ntdb', so sys-libs/tdb-1.2.10 is sufficient. Best, Torsten
I am looking forward to update portage's samba 4 ebuild; however I've found this in the proposed ebuilds: !!>=app-crypt/heimdal-1.5[ssl] As far as I know, samba 4 rc1 works with heimdal . Before doing anything reckless I would know if based on your tests, am I missing something with regard to heimdal?
(In reply to comment #109) > I am looking forward to update portage's samba 4 ebuild; however I've found > this in the proposed ebuilds: > > !!>=app-crypt/heimdal-1.5[ssl] > > As far as I know, samba 4 rc1 works with heimdal . Yes, it does. But so far it didn't compile, while heimdal was build with USE="ssl". Didn't re-check this with rc1, though. > Before doing anything reckless I would know if based on your tests, am I > missing something with regard to heimdal? I'm not going to be near my development box anytime soon, so if you could just try the following: * drop this line from the DEPENDS of the rc1 ebuild * build latest heimdal with USE="ssl" * try building rc1. If it builds, it should be fine to leave out the mentioned line and I'd be happy to see your commit soon. :-) ---- If, on the other hand, the build fails: * rebuild heimdal with USE="-ssl" * try building of rc1 again If this time all goes well, the line needs to stay in place. On my system, btw., there's no other package that depends on having ssl enabled for the heimdal ebuild, so we should be fine commiting the line to portage, at least as long, as we are still in RC stage. Thank you, Torsten
Created attachment 325054 [details] samba 4.0 rc1 ebuild +*samba-4.0.0_rc1 (26 Sep 2012) + + 26 Sep 2012; Víctor Ostorga <vostorga@gentoo.org> + -samba-4.0.0_alpha11.ebuild, +samba-4.0.0_rc1.ebuild: + Version bump of the ongoing samba 4. Ebuild based on the work of Torsten + Kurbad, Ewoud Kohl van Wijngaarden et all at bug 195703 +
(In reply to comment #111) > Created attachment 325054 [details] samba 4.0 rc1 ebuild Thank you, Victor!
I would like to try out samba-4.0.0_rc4 and noticed there are blocks with various packages that demand samba[smbclient]. I take it the [client] flag does not enable equivalent (or compatible) functionality, thus the different naming?
(In reply to comment #113) > I would like to try out samba-4.0.0_rc4 and noticed there are blocks with > various packages that demand samba[smbclient]. I take it the [client] flag > does not enable equivalent (or compatible) functionality, thus the different > naming? Andreas, smbclient is a library provided by the "old", i.e. stable and production ready, Samba 3.x. Samba 4 does, to my knowledge, not provide something similar. Anyway, the question is, what do you want to use Samba for. On a client system, you are perfectly fine with 3.x, because Samba 4 doesn't add any additional functionality to the client side. If, on the other hand, you want to setup an Active-Directory-service, you will need Samba 4, but I'd strongly suggest to use a dedicated system for that purpose, so you won't get into any trouble with unsatisfied USE-dependencies. If you just want to try out Samba 4, I'd suggest a small virtual machine with a minimal Gentoo install as a start. Best, Torsten
Hi, all The samba4 ebuild worked just fine until the rc5. The error I get is: >>>> [2780/2997] Linking default/libcli/nbt/nmblookup4 [2781/2997] Linking default/source4/heimdal_build/samba4kinit [2782/2997] Linking default/source4/heimdal_build/samba4kgetcred /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: default/source4/heimdal/kuser/kgetcred_7.o: undefined reference to symbol 'free_Ticket@@HEIMDAL_ASN1_1.0' /usr/lib/gcc/x86_64-pc-linux-gnu/4.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: note: 'free_Ticket@@HEIMDAL_ASN1_1.0' is defined in DSO /usr/lib64/libasn1.so.8 so try adding it to the linker command line /usr/lib64/libasn1.so.8: could not read symbols: Invalid operation collect2: ld returned 1 exit status Waf: Leaving directory `/var/tmp/portage/net-fs/samba-4.0.0_rc5/work/samba-4.0.0rc5/bin' Build failed: -> task failed (err #1): {task: cc_link print_version_2.o,version_2.o,kgetcred_7.o -> samba4kgetcred} * ERROR: net-fs/samba-4.0.0_rc5 failed (compile phase): * build failed * * Call stack: * ebuild.sh, line 93: Called src_compile * environment, line 5885: Called waf-utils_src_compile * environment, line 6571: Called die * The specific snippet of code: * "${WAF_BINARY}" ${jobs} || die "build failed" * * If you need support, post the output of `emerge --info '=net-fs/samba-4.0.0_rc5'`, * the complete build log and the output of `emerge -pqv '=net-fs/samba-4.0.0_rc5'`. * The complete build log is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc5/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc5/temp/environment'. * Working directory: '/var/tmp/portage/net-fs/samba-4.0.0_rc5/work/samba-4.0.0rc5' * S: '/var/tmp/portage/net-fs/samba-4.0.0_rc5/work/samba-4.0.0rc5' <<<<<<<<<<<<<<< Heimdal version is 1.5.1-r1. Any help appreciated. Thank you.
(In reply to comment #115) > Hi, all > > The samba4 ebuild worked just fine until the rc5. The error I get is: Hi tataia, I can't reproduce your issue on my test system. However, you seem to use a rather outdated gcc version (4.4.5). Current stable version is sys-devel/gcc-4.5.4. Try updating to that version and type gcc-config x86_64-pc-linux-gnu-4.5.4 . /etc/profile Afterwards, try to rebuild both, heimdal and samba.
Hi, Torsten Thank you for your answer but changing gcc to 4.5.4 does not fix it. If I compile from samba git, which uses bundled Heimdal libraries, everything it's ok. I also ran revdep-rebuild to be sure that are not broken libraries. The sistem is up to date. I will try on another gentoo machine to see if I get the same error. Thank you
(In reply to comment #117) > If I compile from samba git, which uses bundled Heimdal libraries, > everything it's ok. Can you post your heimdal and samba USE-flags? ('emerge -v1p app-crypt/heimdal net-fs/samba' will tell you)
Hi, Torten This is the output: # emerge -pv heimdal samba These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] app-crypt/heimdal-1.5.1-r1 USE="berkdb pkinit threads -X -afs -caps -hdb-ldap -ipv6 -otp -ssl -static-libs {-test}" 0 kB [ebuild U #] net-fs/samba-4.0.0_rc5 [4.0.0_rc4] USE="acl cups debug gnutls ldap pam swat -addns -ads -aio -avahi -client -cluster -fulltest -iprint -quota (-selinux) -syslog -winbind" 0 kB Total: 2 packages (1 upgrade, 1 reinstall), Size of downloads: 0 kB
sorry i misspelled your name
(In reply to comment #119) > [ebuild U #] net-fs/samba-4.0.0_rc5 [4.0.0_rc4] USE="acl cups debug > gnutls ldap pam swat -addns -ads -aio -avahi -client -cluster -fulltest > -iprint -quota (-selinux) -syslog -winbind" 0 kB Guess I found your problem: Don't compile samba with the 'gnutls' USE-flag, it does more harm than good. Can you check, whether USE="-gnutls" emerge -v1 net-fs/samba works?
(In reply to comment #120) > sorry i misspelled your name No harm done. :-)
(In reply to comment #122) > (In reply to comment #120) > > sorry i misspelled your name > > No harm done. :-) Hi, Torsten First I also suspected the "gnutls" flag, but it is ok with it. The guilty one is "debug" flag. Without it working, although before rc5 I also had the "debug" flag. Thank you
(In reply to comment #123) > First I also suspected the "gnutls" flag, but it is ok with it. The guilty > one is "debug" flag. Without it working, although before rc5 I also had the > "debug" flag. Thanks for checking that one, too. I think I recall seeing this problem earlier. If I remember correctly, the "--enable-developer" configure option (which is set by the "debug" flag) only works properly for the bundled libs. And while this option was recommended in early alpha stages of Samba 4 to get all the necessary options (and debug output) in, it's since been deprecated for production use. So, qestion to the Gentoo developers: Should we perhaps drop the "debug" use-flag altogether? I don't see any point in supporting "--enable-developer" for a production ebuild.
Hi, I'd like to note, that both rc4 and 5 ebuilds have broken fulltest/test flag. Fulltest requires test, which does not exist. # USE=fulltest emerge -av \=net-fs/samba-4.0.0_rc4 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild UD#] net-fs/samba-4.0.0_rc4 [4.0.0_rc5] USE="acl addns ads aio avahi cluster cups fulltest* gnutls ldap pam quota syslog winbind -client -debug -iprint (-selinux) -swat" 0 kB Total: 1 package (1 downgrade), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-fs/samba-4.0.0_rc4 * samba-4.0.0rc4.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * USE flag 'fulltest' needs these additional flag(s) set: * test * * You can do this by enabling these flags in /etc/portage/package.use: * =net-fs/samba-4.0.0_rc4 test * * You could disable this flag instead in /etc/portage/package.use: * =net-fs/samba-4.0.0_rc4 -fulltest * ERROR: net-fs/samba-4.0.0_rc4 failed (setup phase): * Need missing USE flags * * Call stack: * ebuild.sh, line 93: Called pkg_setup * samba-4.0.0_rc4.ebuild, line 62: Called confutils_use_depend_all 'fulltest' 'test' * confutils.eclass, line 206: Called die * The specific snippet of code: * die "Need missing USE flags" * * If you need support, post the output of `emerge --info '=net-fs/samba-4.0.0_rc4'`, * the complete build log and the output of `emerge -pqv '=net-fs/samba-4.0.0_rc4'`. * The complete build log is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc4/temp/die.env'. * Working directory: '/var/tmp/portage/net-fs/samba-4.0.0_rc4' * S: '/var/tmp/portage/net-fs/samba-4.0.0_rc4/work/samba-4.0.0rc4' >>> Failed to emerge net-fs/samba-4.0.0_rc4, Log file: >>> '/var/tmp/portage/net-fs/samba-4.0.0_rc4/temp/build.log' * Messages for package net-fs/samba-4.0.0_rc4: * USE flag 'fulltest' needs these additional flag(s) set: * test * * You can do this by enabling these flags in /etc/portage/package.use: * =net-fs/samba-4.0.0_rc4 test * * You could disable this flag instead in /etc/portage/package.use: * =net-fs/samba-4.0.0_rc4 -fulltest * ERROR: net-fs/samba-4.0.0_rc4 failed (setup phase): * Need missing USE flags * * Call stack: * ebuild.sh, line 93: Called pkg_setup * samba-4.0.0_rc4.ebuild, line 62: Called confutils_use_depend_all 'fulltest' 'test' * confutils.eclass, line 206: Called die * The specific snippet of code: * die "Need missing USE flags" * * If you need support, post the output of `emerge --info '=net-fs/samba-4.0.0_rc4'`, * the complete build log and the output of `emerge -pqv '=net-fs/samba-4.0.0_rc4'`. * The complete build log is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc4/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc4/temp/die.env'. * Working directory: '/var/tmp/portage/net-fs/samba-4.0.0_rc4' * S: '/var/tmp/portage/net-fs/samba-4.0.0_rc4/work/samba-4.0.0rc4' # USE=fulltest emerge -av \=net-fs/samba-4.0.0_rc5 These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R #] net-fs/samba-4.0.0_rc5 USE="acl addns ads aio avahi cluster cups fulltest* gnutls ldap pam quota syslog winbind -client -debug -iprint (-selinux) -swat" 0 kB Total: 1 package (1 reinstall), Size of downloads: 0 kB Would you like to merge these packages? [Yes/No] >>> Verifying ebuild manifests >>> Emerging (1 of 1) net-fs/samba-4.0.0_rc5 * samba-4.0.0rc5.tar.gz SHA256 SHA512 WHIRLPOOL size ;-) ... [ ok ] * USE flag 'fulltest' needs these additional flag(s) set: * test * * You can do this by enabling these flags in /etc/portage/package.use: * =net-fs/samba-4.0.0_rc5 test * * You could disable this flag instead in /etc/portage/package.use: * =net-fs/samba-4.0.0_rc5 -fulltest * ERROR: net-fs/samba-4.0.0_rc5 failed (setup phase): * Need missing USE flags * * Call stack: * ebuild.sh, line 93: Called pkg_setup * samba-4.0.0_rc5.ebuild, line 62: Called confutils_use_depend_all 'fulltest' 'test' * confutils.eclass, line 206: Called die * The specific snippet of code: * die "Need missing USE flags" * * If you need support, post the output of `emerge --info '=net-fs/samba-4.0.0_rc5'`, * the complete build log and the output of `emerge -pqv '=net-fs/samba-4.0.0_rc5'`. * The complete build log is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc5/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc5/temp/die.env'. * Working directory: '/var/tmp/portage/net-fs/samba-4.0.0_rc5' * S: '/var/tmp/portage/net-fs/samba-4.0.0_rc5/work/samba-4.0.0rc5' >>> Failed to emerge net-fs/samba-4.0.0_rc5, Log file: >>> '/var/tmp/portage/net-fs/samba-4.0.0_rc5/temp/build.log' * Messages for package net-fs/samba-4.0.0_rc5: * USE flag 'fulltest' needs these additional flag(s) set: * test * * You can do this by enabling these flags in /etc/portage/package.use: * =net-fs/samba-4.0.0_rc5 test * * You could disable this flag instead in /etc/portage/package.use: * =net-fs/samba-4.0.0_rc5 -fulltest * ERROR: net-fs/samba-4.0.0_rc5 failed (setup phase): * Need missing USE flags * * Call stack: * ebuild.sh, line 93: Called pkg_setup * samba-4.0.0_rc5.ebuild, line 62: Called confutils_use_depend_all 'fulltest' 'test' * confutils.eclass, line 206: Called die * The specific snippet of code: * die "Need missing USE flags" * * If you need support, post the output of `emerge --info '=net-fs/samba-4.0.0_rc5'`, * the complete build log and the output of `emerge -pqv '=net-fs/samba-4.0.0_rc5'`. * The complete build log is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc5/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/net-fs/samba-4.0.0_rc5/temp/die.env'. * Working directory: '/var/tmp/portage/net-fs/samba-4.0.0_rc5' * S: '/var/tmp/portage/net-fs/samba-4.0.0_rc5/work/samba-4.0.0rc5'
Besides I have a problem with joining a domain created with samba4-rc4. I have 3 PCs all are running few containers in lxc, and all those samba4 AD DCs are in those containers. On 2 of them (which are i686 machines) everything works well. But on a x86_64 machine I cannot join the domain. They all have as similar configuration (package versions use flags) as possible. I'm getting message: # samba-tool domain join mieszko.me DC -WHOME -Uadministrator --realm=mieszko.me Finding a writeable DC for domain 'mieszko.me' Found DC smb4ad02.mieszko.me Password for [HOME\administrator]: Failed to bind - LDAP error 49 LDAP_INVALID_CREDENTIALS - <SASL:[GSS-SPNEGO]: NT_STATUS_LOGON_FAILURE> <> Failed to connect to 'ldap://smb4ad02.mieszko.me' with backend 'ldap': (null) ERROR(ldb): uncaught exception - None File "/usr/lib64/python2.7/site-packages/samba/netcmd/__init__.py", line 175, in _run return self.run(*args, **kwargs) File "/usr/lib64/python2.7/site-packages/samba/netcmd/domain.py", line 552, in run machinepass=machinepass, use_ntvfs=use_ntvfs, dns_backend=dns_backend) File "/usr/lib64/python2.7/site-packages/samba/join.py", line 1082, in join_DC machinepass, use_ntvfs, dns_backend, promote_existing) File "/usr/lib64/python2.7/site-packages/samba/join.py", line 78, in __init__ credentials=ctx.creds, lp=ctx.lp) File "/usr/lib64/python2.7/site-packages/samba/samdb.py", line 56, in __init__ options=options) File "/usr/lib64/python2.7/site-packages/samba/__init__.py", line 114, in __init__ self.connect(url, flags, options) File "/usr/lib64/python2.7/site-packages/samba/samdb.py", line 71, in connect options=options) Info about those systems: # emerge --info Portage 2.2.0_alpha142 (unavailable, gcc-4.6.3, glibc-2.15-r3, 3.7.0-rc7 i686) ================================================================= System uname: Linux-3.7.0-rc7-i686-VIA_Esther_processor_1500MHz-with-gentoo-2.1 Timestamp of tree: Unknown ld GNU ld (GNU Binutils) 2.22 dev-lang/python: 2.7.3-r2::gentoo, 3.2.3::gentoo sys-devel/autoconf: 2.68::gentoo sys-devel/automake: 1.11.6::gentoo sys-devel/binutils: 2.22-r1::gentoo sys-devel/libtool: 2.4-r1::gentoo sys-kernel/linux-headers: 3.4::gentoo (virtual/os-headers) Repositories: x-portage ACCEPT_LICENSE="* -@EULA" CFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=prescott -O2 -pipe -fomit-frame-pointer" DISTDIR="/root/distfiles/" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" GENTOO_MIRRORS="http://distfiles.gentoo.org" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="gssapi kerberos ldap mmx padlock sse sse2 sse3 threads vim-syntax zsh-completion" Unset: ACCEPT_KEYWORDS, EMERGE_DEFAULT_OPTS, PORTAGE_BUNZIP2_COMMAND # emerge --info Portage 2.2.0_alpha142 (default/linux/amd64/10.0/server, gcc-4.5.4, glibc-2.15-r3, 3.7.0-rc7 x86_64) ================================================================= System uname: Linux-3.7.0-rc7-x86_64-Pentium-R-_Dual-Core_CPU_E5700_@_3.00GHz-with-gentoo-2.1 Timestamp of tree: Sat, 01 Dec 2012 01:30:01 +0000 ld GNU ld (GNU Binutils) 2.22 app-shells/bash: 4.2_p37 dev-lang/python: 2.7.3-r2, 3.2.3 dev-util/pkgconfig: 0.27.1 sys-apps/baselayout: 2.1-r1 sys-apps/openrc: 0.11.5 sys-apps/sandbox: 2.5 sys-devel/autoconf: 2.68 sys-devel/automake: 1.11.6 sys-devel/binutils: 2.22-r1 sys-devel/gcc: 4.5.4, 4.6.3 sys-devel/gcc-config: 1.7.3 sys-devel/libtool: 2.4-r1 sys-devel/make: 3.82-r3 sys-kernel/linux-headers: 3.6 (virtual/os-headers) sys-libs/glibc: 2.15-r3 Repositories: gentoo ACCEPT_KEYWORDS="amd64" ACCEPT_LICENSE="* -@EULA Oracle-BCLA-JavaSE PUEL" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=core2 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc" CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/gconf /etc/gentoo-release /etc/sandbox.d /etc/terminfo" CXXFLAGS="-march=core2 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FCFLAGS="-O2 -pipe" FEATURES="assume-digests binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles merge-sync news parallel-fetch preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch" FFLAGS="-O2 -pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j3" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="acl amd64 berkdb bzip2 cli cracklib crypt cups cxx dri fortran gdbm gpm gssapi iconv ipv6 kerberos ldap mmx modules mudflap multilib ncurses nls nptl openmp pam pcre pppd readline session snmp sse sse2 sse3 ssl ssse3 tcpd threads truetype unicode vim-syntax xml zlib zsh-completion" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mmap_emul mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="kexi words flow plan sheets stage tables krita karbon braindump" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" PHP_TARGETS="php5-3" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_2" RUBY_TARGETS="ruby18 ruby19" USERLAND="GNU" VIDEO_CARDS="fbdev glint intel mach64 mga nouveau nv r128 radeon savage sis tdfx trident vesa via vmware dummy v4l" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LINGUAS, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON I've also tried running a i686 lxc container on the x86_64 machine, still no luck. Any ideas what might be wrong there?
(In reply to comment #126) > Besides I have a problem with joining a domain created with samba4-rc4. > [...] Mieszko, this sounds like an upstream issue. Please, seek help in #samba-technical on irc.freenode.net or on one of Samba's mailing lists. Best, Torsten
(In reply to comment #125) > Hi, I'd like to note, that both rc4 and 5 ebuilds have broken fulltest/test > flag. Fulltest requires test, which does not exist. Can one of the Gentoo folks please fix this. Maybe, we should even drop the "fulltest" flag completely and remove local extra_opts="" use fulltest || extra_opts+="--quick" from src_test() and confutils_use_depend_all fulltest test from pkg_setup() FEATURES="test" then enables fulltest by default, which isn't too bad, I suppose.
From the samba-technical mailing list: --- snip --- Subject: [Announce] Samba 4.0.0 Available for Download! Date: Tue, 11 Dec 2012 18:40:26 +0100 ================================================================== "Nothing is impossible, the word itself says 'I'm possible'!" Audrey Hepburn ================================================================== Release Announcements --------------------- This is is the first stable release of Samba 4.0. This release contains the best of all of Samba's technology parts, both a file server (that you can reasonably expect to upgrade existing Samba 3.x releases to) and the AD domain controller work previously known as 'Samba4'. --- snap --- So, how about sorting out the "fulltest" issue and bumping the ebuild? ;-) Best, Torsten
(In reply to comment #129) > From the samba-technical mailing list: > > --- snip --- > > Subject: [Announce] Samba 4.0.0 Available for Download! > Date: Tue, 11 Dec 2012 18:40:26 +0100 > I believe you also need to modify /etc/conf.d/samba file to put only samba4 in daemon_list (In reply to comment #129) > From the samba-technical mailing list: > > --- snip --- > > Subject: [Announce] Samba 4.0.0 Available for Download! > Date: Tue, 11 Dec 2012 18:40:26 +0100 > > ================================================================== > "Nothing is impossible, > the word itself says > 'I'm possible'!" > > Audrey Hepburn > > ================================================================== > > > Release Announcements > --------------------- > > This is is the first stable release of Samba 4.0. > > This release contains the best of all of Samba's > technology parts, both a file server (that you can reasonably expect > to upgrade existing Samba 3.x releases to) and the AD domain > controller work previously known as 'Samba4'. > > --- snap --- > > So, how about sorting out the "fulltest" issue and bumping the ebuild? ;-) > > Best, > Torsten
(In reply to comment #130) > I believe you also need to modify /etc/conf.d/samba file to put only samba4 > in daemon_list Hasn't this been fixed in #444016?
(In reply to comment #131) > (In reply to comment #130) > > I believe you also need to modify /etc/conf.d/samba file to put only samba4 > > in daemon_list > > Hasn't this been fixed in #444016? No. It's still present in 4.0 release ebuild Also the last ebuild requires kerberos useflag for openldap which requires mit-krb5 and this is not suitable for samba4
(In reply to comment #132) > No. > It's still present in 4.0 release ebuild > Also the last ebuild requires kerberos useflag for openldap which requires > mit-krb5 and this is not suitable for samba4 Someone obviously opened a parallel bug report (bug #446926) for the 4.0 release. :-( There, the kerberos dependency has been introduced. I added a note to the other bug report.
*** Bug 447128 has been marked as a duplicate of this bug. ***
*** Bug 446926 has been marked as a duplicate of this bug. ***
Created attachment 332946 [details] samba 4.0 ebuild Finally! We have been waiting more than five years for this.... I've updated the samba 4.0.0 ebuild having the following highlights: * Dropped debug use flag * Dropped fulltest use flag. If you enable tests I suppose you are used to feel pain. In fact, actually tests don't work at all * Restored ldap use flag behaviour * Some cleanup I was thinking about showing a big fat warning before starting the samba 4 build process, because the migration process is not that straightforward, specially for the ldap backend functionality (does it work?) I'll left this bug open until samba 4 is ready for unmask.
(In reply to comment #136) > Finally! We have been waiting more than five years for this.... That's been my first thought, too. :-) > > I've updated the samba 4.0.0 ebuild having the following highlights: > > [...] Thank you, Victor! > I was thinking about showing a big fat warning before starting the samba 4 > build process, because the migration process is not that straightforward, > specially for the ldap backend functionality (does it work?) Yes, the migration from LDAP runs smoothly using 'samba-tool classicupgrade' with the appropriate parameters (The actual process described somewhere in the Samba4 wiki.) However, some advise should be given: * It is HIGHLY recommended NOT to do the migration in place, but to move to a new machine in the process. It is, however, possible to do an inplace migration. If one feels the urge to do so, one should at the very least make sure to have a recent backup of all Samba3-configs, databases, (LDAP-)directories, .... Also a 'quickpkg net-fs/samba' might be a good idea. * In either case, one has to keep the 'old' LDAP (with your Samba3 setup) running. In addition one needs to leave the 'smb.conf' file of the Samba3 setup intact - as said before, the very least to do is a reliable backup. Samba3, however, doesn't need to be running - the 'smb.conf' should suffice. To be honest, I'm not quite sure how to go on about Samba in general. For the time being, only users in need of Active Directory Services would benefit from Samba4, since all the file and print serving parts are shared between versions 3 and 4 now. Also, Samba 3.6 continues to receive maintainance. Has anyone tried to start the 'smbd' and 'nmbd' of a Samba4 installation standalone to 'emulate' the behaviour of Samba3? If that would work, we could offer Samba4 and let the user decide via '/etc/conf.d/samba', whether he wants the AD-parts or just a file- and/or member-server. Any thoughts on this? > I'll left this bug open until samba 4 is ready for unmask. Please do! Thanks, Torsten
(In reply to comment #137) > To be honest, I'm not quite sure how to go on about Samba in general. For > the time being, only users in need of Active Directory Services would > benefit from Samba4, since all the file and print serving parts are shared > between versions 3 and 4 now. > Also, Samba 3.6 continues to receive maintainance. To somewhat answer my own question, here's what Andrew Bartlett posted this morning to the samba-technical mailing list: --- Now that Samba 4.0 has been released - a very proud moment for the whole Samba Team - I want to emphasise something that most of the team has been trying to do over the past few months, but that we haven't really announced: That is, gong forward, we are generally avoiding using the term Samba4 (and Samba3 for that matter). The reason is that while these terms were useful for a time before the merge the originally separate parts of Samba on a technical level, now they just cause us more confusion, and it is only going to get worse now we have made a 4.0 production release. The issue is that Samba 4.0 is a full release of many different Samba components. We didn't make a big fuss about the file server changes, as the biggest changes there are preparation for doing even bigger things in a future release, but what we have done is release a single Samba 4.0. Therefore it is confusing for users and developers when questions are asked about samba4, as while that name generally referred to the AD DC effort, Samba 4.0 is a full Samba release. So, in the future, if you wish to talk about the "Samba 4.0 AD DC", please us that term. The same applies to Samba3 as a term referring to the smbd files server, nmbd, winbindd etc. It is one thing to discuss the Samba 3.x release series, but to talk about the Samba3 components of Samba 4.0 is just confusing. Towards that, I have tried to stop using the term Samba4 in my mailing list posts, and to ensure that folks who mention 'samba4' really do mean the AD DC. I've started editing the Samba4/HOWTO to remove samba4 references, and I've renamed it to https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO There is still a lot to do, but our users can help this a lot by being clear when referring to Samba, and not using these terms. By doing to, we acknowledge that while the big new feature in the Samba 4.0 release is the AD DC, there is much more in Samba 4.0 besides, and we can't do that if we confuse fellow users who might equate Samba4 with Samba 4.0. Thanks, Andrew Bartlett --- So, we should indead simply treat Samba4 as a (major) upgrade to previous releases, while emphazising the fact, that one has to do a migration to Active Directory Services if a Samba based NT4 style domain was used previously. Also, things like "security = server" and "security = share" are gone. But both had long been marked as deprecated in the Samba 3.x builds. Best, Torsten
(In reply to comment #137) > > Has anyone tried to start the 'smbd' and 'nmbd' of a Samba4 installation > standalone to 'emulate' the behaviour of Samba3? > If that would work, we could offer Samba4 and let the user decide via > '/etc/conf.d/samba', whether he wants the AD-parts or just a file- and/or > member-server. I am already using samba-4 as a replacement for samba-3 in terms of smbd/nmbd. Works flawlessly here.
Question: why is this still in package.mask?: # Patrick Lauer <patrick@gentoo.org> (07 Apr 2010) # Keeping samba-4 masked until release. >net-fs/samba-4
(In reply to comment #140) > Question: > why is this still in package.mask?: Did you read the discussion above?
ah I apologize looks like I overlooked a few posts (it is quite a long bug)
I noticed in samba-4.0.0 the ads USE-flag should depend on ldap, but it doesn't and the configure step will fail. Easy to reproduce with USE="ads -ldap" emerge =samba-4.0.0.
Before we can unmask samba 4, several small things have to be fixed. There are, e.g., several packages that depend on sth. like net-fs/samba[smbclient]. Since libsmbclient and its headers are always installed for >=net-fs/samba-4.0.0[client], these packages have to switch to that dependency. In addition, the samba 4 headers are installed in /usr/include/samba-4.0. Packages using samba libraries have to be made aware of that new location, e.g., by appending to CPPFLAGS. To make a start I just filed two bug reports, #452048 and #452050 for media-video/vlc and gnome-base/gvfs. I don't know how developers will react on the append-cppflags hack. Perhaps it would be better to change the samba ebuild to install its headers in a more "standard" location. What do you guys think? Best, Torsten
(In reply to comment #139) > (In reply to comment #137) > > > > Has anyone tried to start the 'smbd' and 'nmbd' of a Samba4 installation > > standalone to 'emulate' the behaviour of Samba3? > > I am already using samba-4 as a replacement for samba-3 in terms of > smbd/nmbd. Works flawlessly here. I can confirm that now.
(In reply to comment #143) > I noticed in samba-4.0.0 the ads USE-flag should depend on ldap, but it > doesn't and the configure step will fail. Easy to reproduce with USE="ads > -ldap" emerge =samba-4.0.0. I have just version bumped to 4.0.1 which fixes the ads USE flag situation and CVE-2013-0172 .
@Torsten Kurbad: I was wondering why you provided a patch a while ago using --with-modulesdir=/usr/lib/$(get_libdir)/ instead of --with-modulesdir=/usr/lib/$(get_libdir)/samba Wouldn't be the second the right way to go?
(In reply to comment #147) > @Torsten Kurbad: > > I was wondering why you provided a patch a while ago using > --with-modulesdir=/usr/lib/$(get_libdir)/ > instead of > --with-modulesdir=/usr/lib/$(get_libdir)/samba > > Wouldn't be the second the right way to go? Nope, it isn't, for two reasons: 1) Both of the lines you state are wrong, because they write into '/usr/lib/lib' or '/usr/lib/lib64', respectively. Have a close look, please! :-) 2) The reason for my patch was (and is) that 'samba' is automatically appended to the value of 'modulesdir', thus if you provide '--with-modulesdir=/usr/$(get_libdir)' the samba modules end up in '/usr/$(get_libdir)/samba' anyway. If, on the other hand, you provide '--with-modulesdir=/usr/$(get_libdir)/samba' the modules are installed into '/usr/$(get_libdir)/samba/samba', thus producing a dead chicken.
Created attachment 335920 [details] Diff with and without samba suffix Heh, I did a typo over there, what I was meaning was --with-modulesdir=/usr/$(get_libdir)/samba I tested this behaviour with 4.0.1 and it seems that I get a proper /usr/lib64/samba and not /usr/lib64/samba/samba. Attached is a diff confirming the above.
(In reply to comment #149) > Heh, I did a typo over there, what I was meaning was > --with-modulesdir=/usr/$(get_libdir)/samba My remark was meant jokingly. I apologize, that this didn't become clear. > I tested this behaviour with 4.0.1 and it seems that I get a proper > /usr/lib64/samba and not /usr/lib64/samba/samba. > > Attached is a diff confirming the above. Ah, okay. Than the former behaviour was probably fixed by the Samba people. Thus, it would definitely be better to go ahead with '--with-modulesdir=/usr/$(get_libdir)/samba'. Sorry for the confusion I've caused!
(In reply to comment #150) > (In reply to comment #149) > > Heh, I did a typo over there, what I was meaning was > > --with-modulesdir=/usr/$(get_libdir)/samba > > My remark was meant jokingly. I apologize, that this didn't become clear. > > > I tested this behaviour with 4.0.1 and it seems that I get a proper > > /usr/lib64/samba and not /usr/lib64/samba/samba. > > > > Attached is a diff confirming the above. > > Ah, okay. Than the former behaviour was probably fixed by the Samba people. > Thus, it would definitely be better to go ahead with > '--with-modulesdir=/usr/$(get_libdir)/samba'. > > Sorry for the confusion I've caused! Thanks for your feedback :) , I've updated samba-4.0.1 to reflect the above.
Created attachment 337004 [details, diff] samba-4.0.1-ebuild.patch Transfer to a python-r1 eclass to avoid errors when using python3 as a active python implementation. Add new dep net-dns/bind-tools[gssapi] when using USE "addns" to avoid this error: /lib/util/util_runcmd.c:334(samba_runcmd_io_handler) /usr/sbin/samba_dnsupdate: /usr/bin/nsupdate: cannot specify -g or -o, program not linked with GSS API Library when starting samba4 as a DC
(In reply to comment #152) > Created attachment 337004 [details, diff] [details, diff] > samba-4.0.1-ebuild.patch > > Transfer to a python-r1 eclass to avoid errors when using python3 as a > active python implementation. > Add new dep net-dns/bind-tools[gssapi] when using USE "addns" to avoid this > error: > > /lib/util/util_runcmd.c:334(samba_runcmd_io_handler) > /usr/sbin/samba_dnsupdate: /usr/bin/nsupdate: cannot specify -g or > -o, program not linked with GSS API Library > > when starting samba4 as a DC This is important, especially for new installs, as the active Python implementation is now Python 3 by default. I tested this patch and it deals with this situation nicely; any chance it could be commited to the tree soon?
(In reply to comment #153) > This is important, especially for new installs, as the active Python > implementation is now Python 3 by default. I tested this patch and it deals > with this situation nicely; any chance it could be commited to the tree soon? + 03 Feb 2013; Sergey Popov <pinkbyte@gentoo.org> +samba-4.0.1-r1.ebuild: + Revision bump: port to python-r1 eclass, add missing dependency, wrt bug + #195703. Thanks to Georgy Kovtunov Added in tree as 4.0.1-r1
Awesome! The new ebuild creates a working Samba install that can be used as an AD DC out of the box. I think the dependency on net-dns/bind-tools[gssapi] should not depend on the "addns" USE flag, though. That flag only causes Samba to be built with --with-dnsupdate, which is not required for the AD DC feature, however the nsupdate tool from bind-tools definitely is.
What's holding back unmasking now? I think the time has come to at least change the message in package.mask. "Keeping samba-4 masked until release" looks outdated now there's already a 4.0.2 release.
(In reply to comment #156) > What's holding back unmasking now? I think the time has come to at least > change the message in package.mask. "Keeping samba-4 masked until release" > looks outdated now there's already a 4.0.2 release. In one word: documentation, Samba 4 documentation related to Gentoo is missing. wiki.gentoo.org needs you all
(In reply to comment #156) > What's holding back unmasking now? I think the time has come to at least > change the message in package.mask. "Keeping samba-4 masked until release" > looks outdated now there's already a 4.0.2 release. In fact, since yesterday, even that one's outdated. The Samba team released 4.0.3 meanwhile... ;-)
(In reply to comment #158) > (In reply to comment #156) > > What's holding back unmasking now? I think the time has come to at least > > change the message in package.mask. "Keeping samba-4 masked until release" > > looks outdated now there's already a 4.0.2 release. > > In fact, since yesterday, even that one's outdated. The Samba team released > 4.0.3 meanwhile... ;-) 4.0.3 is already on portage :)
(In reply to comment #157) > > In one word: documentation, Samba 4 documentation related to Gentoo is > missing. > > wiki.gentoo.org needs you all Having documentation is always fine ofc, but isn't that rather a requirement for arch keyword?
(In reply to comment #160) > (In reply to comment #157) > > > > In one word: documentation, Samba 4 documentation related to Gentoo is > > missing. > > > > wiki.gentoo.org needs you all > > Having documentation is always fine ofc, but isn't that rather a requirement > for arch keyword? Yeah, I also fail to see the point here. Samba 4 documentation can be found on samba.org. Documentation can be seen as an ongoing process. Sooner or later someone will do it for Samba 4 on Gentoo as well. But, there are quite a few packages depending on samba and/or having the "samba" use flag. Some of those packages (gvfs, vlc, gnome-vfs, xine-lib to only name some I encountered) fail to compile with Samba 4. Even worse, some packages, e.g. gvfs, depend explicitily (and unnecessarily) on samba versions < 4. Such a package would therefore prevent you from installing samba 4. The bits needed by these "broken" packages are all there in Samba 4 but the headers are looked for in other places (cf. comment #144). Thus, either this ebuild or the other packages need to be fixed before unmasking. If we don't do that and unmask Samba 4 right away, this bug tracker will be full of people complaining about failing compiles of third party packages that use Samba. Best, Torsten
Torsten, if packages break with samba 4 emerged, could we at least get those listed as blockers for this bug?
As for docs, here's what I've found on wiki.gentoo.org: https://wiki.gentoo.org/wiki/Samba Samba 3 could already serve as a fileserver and an NT Domain controller...the wiki page doesn't address this, though, and only touches on using Samba to mount CIFS shares. For parity with Samba 4, I suppose all that's necessary is to check if mounting details change at all with Samba 4. (I don't *think* they do, but I don't know; all I know is that I've heard upgrades from Samba 3 to Samba 4 are supposed to Just Work...) https://wiki.gentoo.org/wiki/Kerberos_Windows_Interoperability#Samba No idea if this is still explicitly correct for Samba 4. It'd need to be looked into. https://wiki.gentoo.org/wiki/NTP Mentions samba, but doesn't provide any detail apart from a USE flag description. More information (i.e. how to configure samba to use it) might be nices. Dunno if it's necessary, given, again, there's nothing on the wiki about using Samba 3 as a fileserver, much less an NT Domain controller, much less an AD domain controller. https://wiki.gentoo.org/wiki/CUPS_as_printer_client_for_Microsoft_server Verify this process still works with Samba 4, I suppose. There's really not much on the wiki about Samba, period, much less anything specific to Samba 3 vs Samba 4. Certainly, more documentation would be nice, but it's not clear that what exists is *wrong*, and there's certainly a great deal of centralized docs (albeit not exactly clear for the AD case; I've waded through them) upstream.
(In reply to comment #162) > Torsten, if packages break with samba 4 emerged, could we at least get those > listed as blockers for this bug? Right. I've added #452048 and #452050 as dependencies for a start...
Incidentally, I completed an emerge -e @world on my home server after installing Samba 4, without error. Neither VLC nor gvfs are installed on that machine. 480 packages rebuilt. After I finish going through the elogs (routine, natch), I'll run it again. If it comes up clean a second time, I'd say things are probably in good shape. (Perhaps a tinderbox run would be warranted?)
So, /etc/init.d/samba should probably not try to manage smbd and nmbd. It looks like (but I haven't explicitly confirmed this) the samba binary is supposed to manage those daemons itself: # /etc/init.d/samba start * samba -> start: smbd ... * start-stop-daemon: failed to start `/usr/sbin/smbd' [ !! ] * samba -> start: nmbd ... * start-stop-daemon: failed to start `/usr/sbin/nmbd' [ !! ] * Error: starting services (see system logs) * samba -> stop: smbd ... * start-stop-daemon: no matching processes found [ ok ] * samba -> stop: nmbd ... * start-stop-daemon: no matching processes found [ ok ] * ERROR: samba failed to start
I'm currently on step 5 ("Starting Samba as an AD DC") at https://wiki.samba.org/index.php/Samba_AD_DC_HOWTO ... the smb.conf file generated by "samba-tool domain provision" does not address printers. Default behavior regarding contacting cups is...odd: 2013-02-21T23:11:19.300988-05:00 kaylee smbd[8806]: [2013/02/21 23:11:19.300902, 0] ../source3/smbd/server.c:1280(main) 2013-02-21T23:11:19.301030-05:00 kaylee smbd[8806]: standard input is not a socket, assuming -D option 2013-02-21T23:11:21.871512-05:00 kaylee smbd[8822]: [2013/02/21 23:11:21.871234, 0] ../source3/printing/print_cups.c:151(cups_connect) 2013-02-21T23:11:21.871613-05:00 kaylee smbd[8822]: Unable to connect to CUPS server /var/run/cups/cups.sock:631 - No such file or directory 2013-02-21T23:11:21.872057-05:00 kaylee smbd[8821]: [2013/02/21 23:11:21.871929, 0] ../source3/printing/print_cups.c:528(cups_async_callback) 2013-02-21T23:11:21.872163-05:00 kaylee smbd[8821]: failed to retrieve printer list: NT_STATUS_UNSUCCESSFUL Note that it's trying to access "/var/run/cups/cups.sock:631" ... It's appending the standard IPP port to the end of a UNIX domain socket! That's probably an upstream bug. (Also, it should default to /run instead of /var/run)
(In reply to comment #166) > So, /etc/init.d/samba should probably not try to manage smbd and nmbd. It > looks like (but I haven't explicitly confirmed this) the samba binary is > supposed to manage those daemons itself: We discussed this earlier and it worked for me (and others). Nonetheless, running the 'samba' daemon OR 'smbd' and 'nmbd' is mutually exclusive. In other words, if you have 'samba4' in the list, you MUST NOT have 'smbd' and 'nmbd' in there and vice versa. We tried to make that clear in the comment in '/etc/conf.d/samba' That is because the 'samba' binary will bind to most of the ports that are needed for standalone operation of the other two. Also, you musn't run a 'provision' beforehand, since it inserts samba4-specific stuff into your smb.conf.
(In reply to comment #167) > Default behavior regarding contacting cups is...odd: Yes. A very good place to go with such things (if you want a quick answer) is the samba team's IRC channel '#samba-technical' on irc.freenode.net. There's a good chance someone there might explain what's going on with samba4 and printers.
(In reply to comment #166) > # /etc/init.d/samba start > * samba -> start: smbd ... > * start-stop-daemon: failed to start `/usr/sbin/smbd' > [ !! ] > * samba -> start: nmbd ... > * start-stop-daemon: failed to start `/usr/sbin/nmbd' > [ !! ] > * Error: starting services (see system logs) Could you try to find out, WHY the daemons fail to start for you? E.g., run them "by hand" with the '-F' (foreground) option and a high debug level?
I've just been going through "Using Samba 3rd Edition" and the upstream samba wiki. "samba" started by hand just fine. smbd and nmbd failed for this reason: 2013-02-21T23:07:20.909022-05:00 kaylee smbd[8771]: [2013/02/21 23:07:20.908940, 0] ../source3 /smbd/server.c:1252(main) 2013-02-21T23:07:20.909056-05:00 kaylee smbd[8771]: server role = 'active directory domain co ntroller' not compatible with running smbd standalone. 2013-02-21T23:07:20.909062-05:00 kaylee smbd[8771]: You should start 'samba' instead, and it will control starting smbd if required 2013-02-21T23:07:20.911264-05:00 kaylee /etc/init.d/samba[8770]: start-stop-daemon: failed to s tart `/usr/sbin/smbd' 2013-02-21T23:07:20.940519-05:00 kaylee /etc/init.d/samba[8774]: start-stop-daemon: failed to s tart `/usr/sbin/nmbd' 2013-02-21T23:07:20.944300-05:00 kaylee /etc/init.d/samba[8777]: Error: starting services (see system logs) 2013-02-21T23:07:20.951708-05:00 kaylee /etc/init.d/samba[8779]: start-stop-daemon: no matching processes found 2013-02-21T23:07:20.960520-05:00 kaylee /etc/init.d/samba[8782]: start-stop-daemon: no matching processes found 2013-02-21T23:07:20.962985-05:00 kaylee /etc/init.d/samba[8761]: ERROR: samba failed to start (and, incidentally, I simply didn't notice /etc/conf.d/samba :) )
Regarding the CUPS socket...I'm not trying to get Samba printer sharing working. I'm merely reporting two probable bugs in the default behavior: 1) It's looking for a UNIX domain socket under /var/run/* instead of /run/* 2) It's appending a TCP port number to a UNIX domain socket path. I'm reporting these here for informational purposes, as I'm a Gentoo user; I don't have time to pursue them upstream. (Indeed, I'm really not the guy you want for that, if you want them fixed upstream; I'm not motivated enough to aggressively pursue them.)
Good news wrt Samba4 and MIT Kerberos: https://lists.samba.org/archive/samba/2013-February/171896.html Information in question: "In any case, if you want to use a system MIT kerberos, we require 1.8 in source3 and 1.9 in the top level build. Earlier versions are not able to support our requirements, which is why we bundle a known working version of Heimdal." So, we should be able to support app-crypt/krb5 so long as we're using 1.9 or better.
Just for reference: I found a bug in the ebuild that was introduced somewhere after 4.0.0 (Bug #465956). At first I thought it was an ldb problem, but it turned out to be a wrong "mv" statement in all the net-fs/samba-4.0.x ebuilds currently in portage.
samba-4.x is in the tree for quite a while now. Closing this bug as it has grown way too big to track any further problems. If you still find anything that needs fixing in our samba-4.x ebuilds please file new bugs and make them block bug #489762.
