×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Samba 4 Enters Beta

Soulskill posted about 2 years ago | from the progress-is-made dept.

Networking 170

rayk_sland writes "Progress is being made on the long awaited Samba 4 release. On Tuesday the Samba 4 team announced their first beta. Those of us who refuse to have a closed-source server at the core of our networks will be encouraged to see this milestone. Here are a few of the new features: 'Samba 4.0 beta supports the server-side of the Active Directory logon environment used by Windows 2000 and later, so we can do full domain join and domain logon operations with these clients. ... Samba 4.0 beta ships with two distinct file servers. We now use the file server from the Samba 3.x series 'smbd' for all file serving by default. For pure file server work, the binaries users would expect from that series (nmbd, winbindd, smbpasswd) continue to be available. Samba 4.0 also ships with the 'NTVFS' file server. This file server is what was used in all previous alpha releases of Samba 4.0, and is tuned to match the requirements of an AD domain controller. We continue to support this, not only to provide continuity to installations that have deployed it as part of an AD DC, but also as a running example of the NT-FSA architecture we expect to move smbd to in the longer term. ... Finally, a new scripting interface has been added to Samba 4, allowing Python programs to interface to Samba's internals, and many tools and internal workings of the DC code is now implemented in python.'"

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

170 comments

Comments? (-1)

Anonymous Coward | about 2 years ago | (#40229847)

Crickets chirp as a tumbleweed slowly rolls by.

Big shoutout to Tridge and the whole Samba team (5, Interesting)

Tough Love (215404) | about 2 years ago | (#40229855)

Way to school Microsoft on their own technology!

Re:Big shoutout to Tridge and the whole Samba team (1, Funny)

buchner.johannes (1139593) | about 2 years ago | (#40229937)

Way to school Microsoft on their own technology!

Perhaps those are the fruits of the Novell/Microsoft collaboration dedicated to enhanced interoperability ...

Re:Big shoutout to Tridge and the whole Samba team (2, Insightful)

Anonymous Coward | about 2 years ago | (#40230039)

It is much more likely that these are the fruits of long years of dedicated and hard work. In my books, the collaboration you mentioned is just the icing of the cake that is samba. When you have a look at, for instance, .Net/Mono you can easilly see how one-sided that collaboration is.

Re:Big shoutout to Tridge and the whole Samba team (5, Insightful)

Anonymous Coward | about 2 years ago | (#40230335)

Uhh nope. More like the fruits of the Samba team sticking to their guns in the EU and microsoft being forced to open up their protocols.

Re:Big shoutout to Tridge and the whole Samba team (4, Interesting)

Bengie (1121981) | about 2 years ago | (#40230899)

MS didn't just open up their protocol, they invited the SAMBA team, had 2 SMB/Network lead engineers to answer their questions, and gave them a full Linux+Windows environment to play around and test different things.

Re:Big shoutout to Tridge and the whole Samba team (-1)

Anonymous Coward | about 2 years ago | (#40230089)

School how?
Not to knock the Samba team, and I'll deffinitely be taking this for a spin, but It's taken twelve years to release a beta of Windows 2000 Primary Domain Controller functionality, replicating portions of decade old tech is not exactly what one would call schooling anyone.

Re:Big shoutout to Tridge and the whole Samba team (5, Insightful)

Tough Love (215404) | about 2 years ago | (#40230321)

Microsoft fought interoperability in every way they could using fair means or foul, legal or illegal. And still it did not stop the Samba team. The fact that Microsoft managed to slow them down for years is a testament to... something. Not anything nice.

Domain controllers are really the last bastion of Microsoft's illegal barriers to interoperability. This is a big deal.

Re:Big shoutout to Tridge and the whole Samba team (0)

Anonymous Coward | about 2 years ago | (#40230703)

Yes but that's hardly "schooling" Microsoft which is the claim being made.

Re:Big shoutout to Tridge and the whole Samba team (4, Informative)

Ed Avis (5917) | about 2 years ago | (#40231223)

Since a European Union antitrust ruling, Microsoft has been co-operating with the Samba team by providing them documentation. This is a news article from 2008: http://lwn.net/Articles/262891/ [lwn.net] Sure, it's only because they have been forced to, so Microsoft may not get any points for being nice; but my understanding is that the Samba guys have been pleasantly surprised by the working relationship they now have with their opposite numbers at MS.

Re:Big shoutout to Tridge and the whole Samba team (0, Redundant)

Anonymous Coward | about 2 years ago | (#40230135)

Meh. Sun had CIFS in the Solaris kernel 5 years ago.

Re:Big shoutout to Tridge and the whole Samba team (3, Interesting)

Tough Love (215404) | about 2 years ago | (#40230365)

Meh. Sun flushed itself down the toilet and Solaris is on life support. Do we care about Sun's substandard Samba clone?

Re:Big shoutout to Tridge and the whole Samba team (2)

drinkypoo (153816) | about 2 years ago | (#40231115)

Do we care about Sun's substandard Samba clone?

Not since it became Oracle's substandandard Samba clone. I wouldn't fuck them with a stolen dick.

Re:Big shoutout to Tridge and the whole Samba team (3, Informative)

isorox (205688) | about 2 years ago | (#40230665)

Meh. Sun had CIFS in the Solaris kernel 5 years ago.

Err, cifs has been around for years in the linux kernel (as a module), and smbfs before that has been around since at least June 96

Re:Big shoutout to Tridge and the whole Samba team (4, Insightful)

geekopus (130194) | about 2 years ago | (#40230827)

This is about much more than just the filesystem. You can run a full-on AD controller now, complete with group policies, etc. It really is a drop-in replacement for most of Active Directory does.

Re:Big shoutout to Tridge and the whole Samba team (1)

LordLimecat (1103839) | about 2 years ago | (#40231147)

Does it fully replicate how halfbaked the printer GPOs are? That part is really important.

Re:Big shoutout to Tridge and the whole Samba team (1)

Anpheus (908711) | about 2 years ago | (#40231641)

Hopefully they have a properly implemented Quirks Mode that lets me simulate the unending horror that is deploying printers with user/computer policy GPOs.

Re:Big shoutout to Tridge and the whole Samba team (-1)

Anonymous Coward | about 2 years ago | (#40231511)

Heh! And Apple's from-scratch implementation of CIFS in OS X Lion is *infinitely* better than the gpl-infested-crap coming out of the samba people. Basically, anyone who avoids the communistic bullcrap GPL is already ten steps ahead of everyone else.

Think different.
Think better.
Think APPLE!

Re:Big shoutout to Tridge and the whole Samba team (0)

Tough Love (215404) | about 2 years ago | (#40230289)

Way to school Microsoft on their own technology!

What, some Microsoft astromod resents being schooled? Get used to it.

yeah, but... (0)

Blymie (231220) | about 2 years ago | (#40229871)

Yeah.. but does printing work yet? :P It's been broken for what?

A decade?

Re:yeah, but... (-1)

Anonymous Coward | about 2 years ago | (#40229903)

Are you stupid?

What's broken?

Re:yeah, but... (3, Informative)

Anonymous Coward | about 2 years ago | (#40229907)

He's a Mac user. Samba/Cups keeps falling over on OSX.

Re:yeah, but... (3, Funny)

Anonymous Coward | about 2 years ago | (#40230143)

so yes, he is stupid

Re:yeah, but... (2)

laffer1 (701823) | about 2 years ago | (#40230861)

Apple doesn't ship Samba in Lion. Things worked better with Samba, but they wanted to avoid the GPLv3.

Re:yeah, but... (1)

cobbaut (232092) | about 2 years ago | (#40230193)

Are you stupid?

What's broken?

There has been no support for printing in Samba4 ever...
Same goes for a forest trust. These two are stoppers for many companies to switch to Samba4, everything else works fine.

Re:yeah, but... (1)

Anonymous Coward | about 2 years ago | (#40230279)

Exactly. It's not "broken", it's simply not there.

That's like saying SQL support is broken in Samba4.

Printing can be implemented pretty well with Samba3.

Re:yeah, but... (2)

drinkypoo (153816) | about 2 years ago | (#40231197)

Oddly enough, I have never had trouble making windows print to a Unix print queue. Of all the interoperability issues between Windows and Linux, printing has been the least of my problems.

Off Topic (1, Funny)

Anonymous Coward | about 2 years ago | (#40229905)

At present, Slashdot is serving me an advertisment for "Dioralyte".

I'm just wondering why Slashdots customers think that an advertisment for a post-diarrhoea rehydration remedy is appropriate in this environment? Perhaps they think that the rollout of Samba 4 Beta will give Microsoft the shits?

Re:Off Topic (0, Flamebait)

Anonymous Coward | about 2 years ago | (#40230077)

You mean the ads that are served based on you? So, basically /. is saying you were full of shit before.

internals? in python? (2)

epyT-R (613989) | about 2 years ago | (#40229955)

really? god help us all.. I really hope this doesn't affect performance or memory footprint.

Re:internals? in python? (3, Insightful)

Martz (861209) | about 2 years ago | (#40229979)

Why not? It's a new major version which provides new functionality, and is written in python to make it easier for people to contribute.

Memory and CPU have never been cheaper, if you're still running your samba box on a PIII 450MHz then you'll probably want to stay on Samba 3.

Otherwise upgrade your hardware and move to Samba 4 when it becomes stable.

It *WILL* be slower and it *WILL* use more memory, since it's not stable and it's a major new version with new features.

Sheesh.

Re:internals? in python? (0, Redundant)

Anonymous Coward | about 2 years ago | (#40230149)

Why not? It's a new major version which provides new functionality, and is written in python to make it easier for people to contribute.

Memory and CPU have never been cheaper, if you're still running your samba box on a PIII 450MHz then you'll probably want to stay on Samba 3.

Otherwise upgrade your hardware and move to Samba 4 when it becomes stable.

It *WILL* be slower and it *WILL* use more memory, since it's not stable and it's a major new version with new features.

Sheesh.

Isn't this the same critic that people made of Windows and compulsory hardware upgrades for a good decade ?
So now Linux is as bad as Windows. Way to go guys !!!!
Instead of leveraging C and C++ for performance reasons we're going backwards at an alarming rate.
What's next ? Porting the linux kernel to python ? Great Scott.

Re:internals? in python? (4, Insightful)

TheRaven64 (641858) | about 2 years ago | (#40230273)

While I'm certainly not a fan of Python, it's clear that they are leaving the high performance parts in C, and just using Python for scripting. Samba comes with a lot of tools that are not performance critical. For example, the smbtree utility needs to print a pretty tree of the current network from the results of a scan. If the scan is done by the core C code, there's no reason why you can't write the part that parses command-line options, prompts for passwords, and displays the output in an interpreted scripting language: even if it runs at 1% of the speed of C code, users won't notice the difference because almost all of the time will be spent in the code doing the I/O.

Re:internals? in python? (0, Redundant)

adolf (21054) | about 2 years ago | (#40230303)

What about the other users on the same computer who are also using software which is running 100x slower than it could, just because Python (or whatever) is the new hotness?

On a machine that's actually, you know, doing work, cycles count. Hell, even on a single-user netbook or tablet, cycles count, since it negatively influences both heat generation and battery life -- even if it's "fast enough" for a human's interaction.

Intentional (or even incidental) inefficiency is never a positive thing when it comes to computing.

Re:internals? in python? (3, Insightful)

TheRaven64 (641858) | about 2 years ago | (#40230359)

Programming is about picking the right tool for the job (which is never Python, but I digress). There are not going to be 100 users running an admin tool at once. Even that tool is not going to be loading the CPU, because it is going to be spending almost all of its time calling into C libraries. If the choice is writing it in a language that makes it easy to get bug-free and which does not impose any user-visible cost, or writing it in a language that makes what you want to do (e.g. string processing) error prone, likely to be buggy, and does not run detectably faster, then you are an idiot if you pick option 2.

Re:internals? in python? (1, Insightful)

adolf (21054) | about 2 years ago | (#40230453)

You're right: There won't be 100 users running an admin tool (though I view smbtree, in particular, as more of a user tool...at least on the networks I've been paid to use). But there could easily be 100 users running 100 different Python apps which could be more-efficiently coded in...almost anything else.

The problem I see (and I see it more and more, and not just with Python) is that things are becoming more runtime-interpreted and less efficient. Going back some decades, it is often explained that it doesn't matter "these days", but I submit that it does matter -- and always has.

Instead of battling execution time (the CPU in my cell phone is ridiculously faster than my first half-dozen computers even if they're all combined and quadrupled), we're now battling energy efficiency. But other than terminology it's exactly the same game: Interpreted languages may be fast to develop, but cost more for people to use.

Case in point: I, a single user, notice when I'm running inefficient programs on my phone. Things generally happen very fast, but they also cause the hardware to get (sometimes uncomfortably) hot and the battery voltage starts to dive.

smbtree in particular is such a light-duty single-shot thing that it really won't ever matter to me, by itself, but the confluence of that and every other inefficient program makes a real dent in my ability to use my pocket computer and stay away from a charger, which has a real and tabulable cost in terms human time.

And not to be too pessimistic, but to extrapolate: It ought to be possible for a sufficiently-motivated person to ascertain the cost of such inefficient programming techniques in terms of human lives lost.

(Ugh.)

Re:internals? in python? (1)

DarkOx (621550) | about 2 years ago | (#40230497)

To determine if something is efficient or not you first need to decide what you are optimizing for. If electricity usage is your target no the move toward run time interpreters might not be great.

The thing is the more of the platform that is implemented as a collection of single use high performance machine code modules glued together with script code the more adaptable it is to my work flow. I don't have time to deal with all my information sources and various protocols I have to work with in C. Could I implement all that glue in C, yes, with enough wall time I could do that. Then again when Python/Perl/Ruby/Dialect abstractions exist I toss together a script that updates AD, our internal asset database, the HR system, and training/certification system to reflect the status change of 30 interns all in about 15min error free.

Might not work so well on my cell phone but it sure is nice on my laptop. Wall time is more valuable to me than added electricity cost per day.

Re:internals? in python? (1)

adolf (21054) | about 2 years ago | (#40230583)

Perhaps you misunderstand: I don't care about energy cost in terms of dollars: Energy, on the scale that I deal with, is damn-near monetarily free.

I care about two things: How efficiently a multi-user (or otherwise-loaded) machine can use the program, and how long I (as a single user) can operate between charges, or without the device overheating and slowing down or becoming unusable in other ways (dual 1.2GHz ARM cores and no meaningful heatsink == thermal dissipation issues, often to the extent that the device will refuse to charge the battery because the battery is too damned hot to be charged).

Things I don't care about: How long it takes a programmer to figure it out, how convoluted the programmer's learning curve is, and how much he/she hates the process of coding efficiently. With far more honesty than snideness, I really don't care about your problems.

I'm a user and sometimes an administrator, but never a programmer. (Fault me for this if you like.)

It's cool that you can combine all of those things ("error free") in 15 minutes, but: What does it cost? (And, again, I don't mean dollars. Human time is more valuable than money.)

Re:internals? in python? (0)

Anonymous Coward | about 2 years ago | (#40230905)

You're right, human time is usually more valuable than money. That includes developer time.

Perhaps you are content to wait another 5-10 years so everything can be rewritten and debugged in C?

Re:internals? in python? (1)

drinkypoo (153816) | about 2 years ago | (#40231141)

Perhaps you are content to wait another 5-10 years so everything can be rewritten and debugged in C?

If the tools which have been rewritten in python are so complex that they would take 5-10 years to rewrite and debug in C, then they damned sure should have been written in C in the first place, because clearly they contain enough complexity to where the performance will suffer in python.

Re:internals? in python? (0)

Anonymous Coward | about 2 years ago | (#40231229)

So, because you're a lazy hack that entitles you to waste everyone else's time?

Re:internals? in python? (2)

epyT-R (613989) | about 2 years ago | (#40230695)

the cool part about properly coded native programming is that it's suited for a variety of environments.. from big iron servers, to pocket computers with tiny amounts of ram.. the script you talk about is something you run once a day, probably mostly IO bound.. the functions in a system daemon can be called hundreds to thousands of times/second...even more for real low latency and/or high bandwidth stuff. switching to a high level language severely limits the footprint the program can run in usefully.

Re:internals? in python? (5, Insightful)

Anonymous Coward | about 2 years ago | (#40230421)

Intentional (or even incidental) inefficiency is never a positive thing when it comes to computing.

You seem to be under the impression that the most valuable resource in computing is clock cycles.

It's not, not even close.

The most valuable resource in computing is developer time. If writing in Python makes it quicker to develop code (it does, by orders of magnitude), then that is "efficient". I've been writing C programs since the late 80's and even I can see that Python is a productivity win.

I get sick of people that rant about "inefficiency" in clock cycles when here, in the real world, the inefficiencies with the greatest business impact are the ones that cost dev time. Devs are freaking expensive. A dev spending 2 weeks squeezing an extra 0.1% of performance out of a non-critical part of an app is a complete waste of time and money.

By all means, don't make a slow heap of crap (I don't think Samba is). And by all means, for code which is profiling very poorly, impacting the users and hurting the business, look for lower level optimisations.

But please, for everybody's sake, get some perspective on this issue. Just because parts of it are not written in C doesn't mean it's not efficient, because "efficient" covers a heck of a lot more than clock cycles, at least to people who actually have to run a business.

Re:internals? in python? (-1, Flamebait)

adolf (21054) | about 2 years ago | (#40230491)

I'd respond in context, but you're an AC. While I'm interested in discussing these concepts, I prefer to have my discussions with individuals. YMMV.

Re:internals? in python? (1)

Dog-Cow (21281) | about 2 years ago | (#40230603)

In other words, you don't have a reasonable response that is anything other than a personal preference that you wish you could force on everyone else.

Re:internals? in python? (2)

VON-MAN (621853) | about 2 years ago | (#40230843)

Yet you did address him, if only to say that you will not talk with him.

Re:internals? in python? (0)

Anonymous Coward | about 2 years ago | (#40231247)

if you want to talk to me, you know where to find me.

Re:internals? in python? (1)

epyT-R (613989) | about 2 years ago | (#40230657)

The most valuable resource in computing is developer time

that's great for them. what about MY time? and my users' time? I agree that time is money, and senseless nth degree optimizations are pointless, but offloading developer time by dumping bloated turds onto user hardware is a big no no. Every time this comes up, people want me to assume that the time magically disappears! it doesn't. it's offloaded onto the customer! This attitude is probably THE reason why so much software today is bloated beyond reason for a task.. The problem is compounded when the user must run multiple programs written with this attitude. Most developers assume the user's only going to run THEIR program and nothing else when they run their idiotic 'cost analyses.'

properly coded new features worth a small hit in performance are very different from killing it by multiple factors so that a couple of hacks can throw it together in 1/5 the time in a 'managed' runtime. The developers time is only one chunk.. one time+any patching. The time the users waste in slugging through a slow ass program is multiplied by the number of times they have to use it to complete tasks! Then there's the energy footprint and the cost of needless upgrades, not just the cost of the hardware itself, but the downtime associated with its setup and initial hiccups..and for what? so they get the same performance they had before with the old software? what a deal!

clock cycles are 'the' measurement of efficiency if you assume an average percentage of real business level work done per cycle. this includes the user. if the program runs faster than he can, all is good. if he's waiting around for guis to redraw, garbage collection to flush every time he clicks something, or his harddrive to swap out 900MB worth of bulk from all the other bloated software he has to run on his (often already underspec'd) machine, then it costs HIS company time, and him his sanity.

Re:internals? in python? (2)

ratboy666 (104074) | about 2 years ago | (#40231381)

Huh... so a lot of people are wrong.

How many? Hard to count how many people, but we can certainly look at applications.

Let's examine my Fedora 17 laptop. In /usr/bin, 139 programs are written in Python, including my music player (quodlibet), repo management, some of abrt (defect reporting), time tracking, and desktop wiki.

Another 194 are written in Perl, including parts of fvwm, foomatic and callgrind.

388 more are POSIX shell script and 45 bash scripts.

There are 381 symbolic links, 31 hard links (which I now disclude), and 2346 binary executables.

There are 3522 total programs in /usr/bin.

67% binaries, 22% scripts, and 11% links.

[Java applications, and LibreOffice are not counted, but I'd imagine you would probably classify Java apps as scripts too]. This is a freshly upgraded netbook, and (since this is /usr/bin) we have only examined "system" or "distribution" applications.

I guess that 22% must be wrong. If we can extrapolate from applications to developers (hey, I know that is just wrong, but it's better than NO data at all), 1 in 5 developers is shipping scripts.

And that (proudly) includes me.

As to the "900MB"? The python interpreter has a 10kb front-end, and 1.7mb library. Yes, there is some additional overhead.

Let's examine QuodLibet (music player application): 67mb resident, compared to 11mb for Terminal (collecting this data), and 267mb for firefox (as I'm typing this comment).

QuodLibet offers albums, playlists, sophisticated queries, and runs just fine on a NETBOOK.

In Python.

Re:internals? in python? (0)

Anonymous Coward | about 2 years ago | (#40230955)

You should really upgrade your multi-user file-serving tablet to one of the current quad core models; same goes for your mission critical Domain Controller/Render/Database/Application Server.

Seriously, with hardware being a lot cheaper than software and maintainance most businesses aim to buy machines that get the job done under a typical workload. With all the machines of various sizes I have built, none were ever at their peak performance due to file transactions or calculating group policies. Also with the poor I/O of netbooks and tablets, alongside the over 1 GHz CPUs (note: 1 billion steps per second) working in them, neither you, nor the battery will notice a few thousand CPU cycles of overhead dedicated to samba4.

You, Sir, sound like the, dare I say, Gestapo [slashdot.org] of CPU cylces...

Re:internals? in python? (1)

epyT-R (613989) | about 2 years ago | (#40230671)

It still increases dependency hell, and it eliminates efficient scripting of those now 1% as fast operations. then there's embedded systems...

Re:internals? in python? (2)

TheRaven64 (641858) | about 2 years ago | (#40230737)

Oh, I'd agree about that. Scripting in something like Lua, which is a 200KB binary that can be embedded in the tool without much overhead would make sense. Trying to distribute Python programs is usually a disaster in my experience, but that doesn't make the original poster's complaint valid.

Re:internals? in python? (1)

Tough Love (215404) | about 2 years ago | (#40230333)

Give me a break. Samba 4 is not implemented in Python. You're not serious are you? Please tell me you're not serious.

Re:internals? in python? (0)

epyT-R (613989) | about 2 years ago | (#40230551)

umm.. no. This attitude is why it takes a 2ghz cpu and 12GB of ram to push the same data a server with 1/20th the resources was doing a decade ago. We need to re-learn that it's not wise to kill performance at low levels of the stack just to get more people involved. more people need to step up to the challenge, learn C and get it done right (or develop a new, better native language! and code in that). Python is slow as hell no matter how good the programmer is. It's fine for writing administration scripts and such, but it's terrible for low latency, high bandwidth applications like a file/authentication/authorization/allocation server. There's a reason why it's a general rule that system level daemons are written in C. sure I could see python being used to process its log files, or to automate directory creation, but the article uses the word 'internals' which makes me quite nervous about performance.. See, I like the idea that running smbd on a modern machine will actually GAIN me performance that wasn't available 10 years ago. That means more files being served at once, faster, which means users log on more quickly, and get better network performance. Happy users make for a happy sysadmin. I did not buy more cycles so that software developers can replace a few excellent C programmers with many mediocre ones who can't be bothered to learn proper systems programming. As an admin, I'd resent this because what's really happening is that these people are offloading their laziness onto my hardware. Yes, I could stick with existing software, but that's not really tenable in the long term.

now I could be wrong, as this summary is thin on details about 'internals', and I did not dig deeper, but if this is true, samba 4 is about to become the latest victim to the bloat craze of the 21st century. There is a BIG difference between a program being slower because of properly coded new features that justify the impact and emotionally driven development tool changes that blatantly waste cycles for politics.

Re:internals? in python? (4, Informative)

Dog-Cow (21281) | about 2 years ago | (#40230621)

You are basically completely wrong about what the Samba team has done. All the daemons and such are still written in C (and/or C++). Did you really think that they would rewrite Samba from the ground up in an interpreted language?

All they have done is provide a scripting interface with bindings for Python. I don't know if the interface is generic enough to be used by other scripting languages, but that's irrelevant. The point is that you can script Samba, not that Samba is a script.

Re:internals? in python? (1)

epyT-R (613989) | about 2 years ago | (#40230729)

I am glad to hear that, and honestly I doubted it, but the summary made me wonder with its choice of vocabulary, and trends these days would make me unsurprised if it was true. there is talk that the admin tools are now python based.. that does have implications if already existing scripts depend on rapid calling/scraping of admin utils.

Re:internals? in python? PLEASE! (0)

Anonymous Coward | about 2 years ago | (#40231317)

Memory and CPU have never been cheaper, if you're still running your samba box on a PIII 450MHz then you'll probably want to stay on Samba 3.

Please save this hackneyed retort for the Python programmers user group meetings.

Perhaps you missed the current and refreshing trend towards cheaper, fanless, low powered computing devices. Think embedded and NAS. Even if hardware is cheaper than it was, that doesn't mean we want to waste our money. But, more importantly, we don't want to suffer noise, heat, size or power consumption unnecessarily.

Your stock programmers mantra is not only wasteful, it is why we need a quad core 3Ghz with oodles of RAM to do the same work, in the same slow time, that we did 15 years ago with the 450Mhz PIII you cited.

SAMBA is a file server. A very basic function that should not require orders of magnitude increases in computing power with every iteration because of lazy programmers. The ultimate work output, sharing files and directory service, remains unchanged, so why must we make the software huge and slow?

I get that Work == Hard, but that doesn't mean that it shouldn't be done.

Interesting, to say the least (3, Interesting)

ameen.ross (2498000) | about 2 years ago | (#40230003)

I've first tested Samba 4 around alpha 11. It was certainly an interesting learning experience and it was also surprisingly stable for an alpha product. I'd love to play around with it again after 2 years of development.

Re:Interesting, to say the least (3, Informative)

Anonymous Coward | about 2 years ago | (#40230853)

I have an active Samba4 testbed intergrated to a huge AD structure and until alpha17 I've had all sorts of issues. However I now have alpha19 and things have changed considerably - it's working to the point where I have put a Samba4 test controller into production and have seen this Just Work once installed correctly.

However the official Samba4 install docs are shit. I had to work out a HOWTO that with the help of a few searches to fine tune it, that after a lot of work Just Works as well. You have to install and configure BIND, krf5, ntp etc one by one in the right order and get it right or you are screwed. I spent a few hours today knocking up a internal HOWTO based on all of that and it's now the install process I'm happy with and can execute in 15 minutes

The issues I see with Samba is not wether is nearing production ready or not - its a prick to install correctly if you don't do a lot of testing and research (which is why I despair at the wiki install process, frankly it's not worth spit) - which is why I think a lot of admins run into real deep trouble at first and often just give up. You also do need good working AD knowledge, an area a lot of Linux admins just do not have. You also need good Linux knowledge, something most Windows Admin just do not have. In other words, it doesnt allow clicktards to use it. You need to know what the fuck you are doing.

But when I have an Exchange 2010 platform referencing the Samba4 controller as it's DC, that's a really good test to see that it all really does work and works so well that even a AD sensitive application like Exchange has no idea it's not talking to a W2K8 controller.

So, summary - since Alpha18, Samba4 has become good enough to Just Work, no MS server knows the difference and someone with experience of NT back to 3.1/3.5 days is happy with how it works. However Samba really need to get the install documentation in much better shape or even simply point to HOWTO's that do work, so that they get more people to actually be able to USE the damn thing so you dont have to go through what I did to get to the point where I am. Take my advice, find a good HOWTO from somewhere that ISNT the Samba4 wiki and you will have a much better experience. Still not clicktard level easy and I suspect never will be..... but frankly clicktards should be staying the fuck away from SysAdmin anyway.

Obsolete Bleah (0)

Anonymous Coward | about 2 years ago | (#40230013)

Tridge is so super talented. Wish he had focused on rsync....

Re:Obsolete Bleah (1)

Tough Love (215404) | about 2 years ago | (#40230347)

Tridge is so super talented. Wish he had focused on rsync....

Why? It's perfectly well maintained by others, his talent is needed in other places. By the way, if you think rsync is cool, check out rzip.

Re:Obsolete Bleah (0)

Anonymous Coward | about 2 years ago | (#40230565)

Your wish has come true, he did focus on rsync. That's what he did his PhD on!

And he implemented it and essentially finished it (or developed most of the fundamentals for it). That was good of him.

Licence (1, Interesting)

psergiu (67614) | about 2 years ago | (#40230051)

Under what licence is Samba 4 published ? Still the restrictive GPLv3 or they adopted a more permissive licence that won't scare the legal teams everywhere ?

GPL *is* the most permissive license... (-1)

Anonymous Coward | about 2 years ago | (#40230161)

to all except to the leeches, that is.

Re:GPL *is* the most permissive license... (1)

Dog-Cow (21281) | about 2 years ago | (#40230631)

GPLv3 is very restrictive with respect to developers. It's fairly open from the perspective of a user.

Re:GPL *is* the most permissive license... (1)

LordLimecat (1103839) | about 2 years ago | (#40231423)

You have a funny definition of permissive that seems to include "has restrictions". The "most permissive license" would be one that imposed no use restrictions whatsoever-- which GPLv3 (and v2) does not qualify for.

You might say that its the "most free" or "most open" or "most consumer friendly", and possibly some might agree with you, but certainly not most permissive.

Re:Licence (1)

nzac (1822298) | about 2 years ago | (#40230313)

If you wanted to sell ad ons, you should sell them to Windows server users.
I can't see how GPL would get in the way of internal use, you never distribute anything.

Re:Licence (1)

psergiu (67614) | about 2 years ago | (#40230773)

How do you define "internal use" ? One subnet ? One building ? One department ? One company ? Multiple subsidiaries registered in different counties ? And what if someone not considered "internal" in one of the above ways sccesses (by mistake or unlawfuly) your software ?

How do you persuade a company legal team that GPLv3 is not poison and let the techies use GPLv3-licenced software ?

Re:Licence (1)

nzac (1822298) | about 2 years ago | (#40231035)

the legal they use in the is "convey":
To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
http://www.gnu.org/copyleft/gpl.html [gnu.org]

A company carrying out work on the code and keeping it for them selves (same party), does not convey the code and does not run into any GPL clauses. If they they are legally two parties then as long as the second party can be trusted (you cant legally enforce it, as per the license) to not further convey the source, i think your fine as well.

How do you persuade a company legal team that GPLv3 is not poison and let the techies use GPLv3-licenced software ?

Get them to read the license. It only covers conveying of the source code as far as i can see. If you want to use it in a product you want to sell then they have every reason to get worried about it.

Re:Licence (0)

psergiu (67614) | about 2 years ago | (#40230739)

I see that i have been modded down - but that's the truth.

In the "real world" GPL3 is restrictive. At many corporations, the legal teams have forbade usage of any GPL3 software. I am also impacted by this at my work place - we have to do with older versions or commercial software as according to the "suits" a Microsoft Server licence & support contract are way cheaper than a lawsuit.

And this goes especially true for Samba - as GPL3 is worded, you are not allowed to use-it to serve protected files, or, if you do, it's fair game to anyone to steal your data as this whole "domain authentication" stuff is Digital Rights Management. So the lawyers say, and management will listen to the lawyers and not the engineers.

For home use - GPL3 is peachy - but noone has the need at home for AD & other advanced stuff that Samba 4 brings. The large networks - who could have benefited from Samba - will will keep making Microsoft rich because of the above reasons - and that's a friggin' shame.

Re:Licence (0)

Anonymous Coward | about 2 years ago | (#40230897)

And this goes especially true for Samba - as GPL3 is worded, you are not allowed to use-it to serve protected files, or, if you do, it's fair game to anyone to steal your data as this whole "domain authentication" stuff is Digital Rights Management. So the lawyers say, and management will listen to the lawyers and not the engineers.

This is complete fantasy.

Re:Licence (0)

Anonymous Coward | about 2 years ago | (#40230989)

Hah. You're a fucking nincompoop. You're living in your own little fantasy land.

Re:Licence (1)

LordLimecat (1103839) | about 2 years ago | (#40231477)

And this goes especially true for Samba - as GPL3 is worded, you are not allowed to use-it to serve protected files, or, if you do, it's fair game to anyone to steal your data as this whole "domain authentication" stuff is Digital Rights Management.

Im no lawyer, but that sounds like absolute nonsense. DMCA for example means that even if it is technically feasible to crack DRM, it is (or can be? not a lawyer) illegal to do so.

And if the files being served are company property, for another entity to gain access to them in an unauthorized fashion would certainly run afoul of several anti-hacking laws, at the very least.

Further, GPL says NOTHING about what you can or cannot do with compiled binary IIRC-- all of the scary restrictive stuff has to do with redistribution and modification.

Your legal team is incompetent if they think the GPL has any implications for anyone who isnt a developer specifically working on (or deriving from) the GPL'd source code.

2002 (1, Interesting)

lkcl (517947) | about 2 years ago | (#40230139)

luke howard implemented Active Directory, in XAD, and released a product in 2002 (bought recently by novell). he used samba, freedce, heimdal and openldap, providing patches for each that hooked in the services that he implemented.

what he *did not* do was implement an entire LDAP server from scratch, implement an entire DCE/RPC runtime from scratch, implement an entire kerberos server from scratch.

i spoke to someone who used to be a big supporter of samba and was a prominent and active member of the samba team, last year. when i was working on samba-tng, he had 20 customers. ten years later that number is down to THREE - all others have gone back to NT Domains on Windows. one of those three is honest enough to tell him that they HATE samba, with a vengeance. they are bitterly disappointed, and the only reason that they are still using samba is because they are forced to.

the work i did on samba-tng *would* have proceeded to Active Directory interoperability *if* the samba team had not been so hostile towards it. in essence the samba team leaders felt threatened by my abilities, and did not wish me to become the technical lead [by default]. they simply did not understand the scope or scale of the task, were unable to fully grasp it, and to some extent they still don't. twelve YEARS later we see the results of their decisions and actions. what can i say?

Re:2002 (0)

Anonymous Coward | about 2 years ago | (#40230355)

Maybe because it was a steaming pile of spaghetti code..

Re:2002 (3, Interesting)

ledow (319597) | about 2 years ago | (#40230443)

I'm sorry, but if you could have done it ten years ago, maybe you should have. And released the product, and get bought out, and made lots of money, and proved everyone wrong. Hell, you still have a lot of time because Samba still has a LONG way to do yet.

Samba's AD implementation has been a long time coming but personally EVERY prior attempt I've seen, including quite a lot of samba-tng, was horrendously hacky. Having to install and configure perfectly 5-6 entirely independent dependencies is not a good recipe to test or debug code on (one tweak to one config file and samba would stop working for a user and it could take hours to spot that difference and massive amounts of reinstalling, reconfiguring and sending logs and configs back and forth). I took several looks at solutions over the intervening years but nothing was even close to risking the time to install them, let alone test the results. And believe me, I looked at anything and everything that came up.

From what I saw, most of the patching to get things like samba-tng etc. working code-wise was horrendously hacky and basically the equivalent of rewriting the spec - while Kerberos might be paid lip-service by MS, their variants are quite different and not the kind of thing you want polluting an otherwise independent codebase.

Trying to get patches to 5+ different projects in order to fix your non-standards-compliant implementation of a protocol sounds like a political nightmare from the start, let alone doing it for the sake of purely Windows hangers-on. At no point did anybody just fork those projects and create their own versions, either, except to rewrite independent implementations. Not reinventing the wheel does not take a genius, and I have no doubt that EVERY step possible to avoid that was taken.

Without even looking into the details, I would consider it Plan B to have to push massive amounts of patches to five other HUGE projects just to get something close to beginning working so you can start testing, in terms of actually getting something out to others for them to use in stable systems (for testing, debugging, sure, use whatever hacky solutions you like) .

Fact is that over the last ten years NOBODY else has actually stepped forward and done this work, except for proprietary, closed-source solutions (all of which have problems - hell, even Apple's implementation is basically borked) and Samba.

Projects forks are ten-a-penny on large OS projects but yet nobody stood up and said "Damn, he's right, let's fork samba-tng to get this stuff going and worry about the politics later!". And at any point, you could suck in the Samba4 work for yourself to help you diagnose, test against, etc.

I hear a lot of "I could have", but never much "I did". I'm not saying I could do the work at all, but the vast majority of the people who actually stepped up to the plate were in the Samba team. And nobody else, on any other open-source project, "beat" them to it - even with the help of the EU courts and Microsoft itself. That suggests that maybe the task was slightly more tricky than just slapping things together.

AD implementations are also not the kind of thing you take chances with. If one machine dies because of a dodgy kernel, who cares, you can do something about it. If your AD structure trashes itself mid-day because of a bad failover to a Samba DC, or a long, slow, push of faulty and subtlely-broken packets makes things irrecoverable, you have a lot more to answer for. That means that even the post-Samba-3 solutions to AD's that I tried would have required YEARS of personal testing before I actually trusted them (and would most probably only see deployment on their own isolated network and AD and then slowly, over years, creep to the point where I was confident on just replacing everything with them).

If alternatives existed, and the work was possible, it takes literally MINUTES to set up a code mirror and post your patches and then you can spam it to hell and let people choose their own preference. Fact is, that happened several times post-Samba-3, and could have happened dozens more, and yet nobody else "beat them to it". In fact, nobody else even got close.

Personally, I've been waiting for years for a decent Samba / AD implementation. I would literally deploy it tomorrow if I thought it would act as a full, reliable replacement, as would millions of other people. As it is, it's the *only* candidate worth considering and still a LONG way off working to my satisfaction.

You're a fool if you're telling the truth and you could, quite literally, have made millions.

Re:2002 (1)

lkcl (517947) | about 2 years ago | (#40230725)

I'm sorry, but if you could have done it ten years ago, maybe you should have. And released the product, and get bought out, and made lots of money, and proved everyone wrong. Hell, you still have a lot of time because Samba still has a LONG way to do yet.

Samba's AD implementation has been a long time coming but personally EVERY prior attempt I've seen, including quite a lot of samba-tng, was horrendously hacky.

welcome to reverse-engineering. samba tng was "version 1" of the "three versions required to make a successful project". from not knowing anything, and not having access to the IDL files in any way shape or form it actually provided pretty stable functionality, and broke the ice for the entire CIFS industry. network appliances, sco/tarantella, luke howard's XAD project - all of them could not have been possible without having that code to look at and understand.

luke howard *did* do it [the equivalent of a version 2.0]. he *did* release the product [in 2002]... and he had to hold out for 8 years for a decent offer of a buy-out. everyone kept offering him stupid-money ($100k or less).

so it's not as clear-cut as you think.

i'm not entirely sure if you're aware just quite how many services and protocols are actually involved in "a samba". it's something like... eight separate and distinct networking protocols and something like over thirty separate and in some cases recursively-linked networked services. what i did in samba-tng was to "cut to the chase" and studied it day-in, day-out, often for twelve hours. the return on investment of three years of continuous work? absolutely fuck-all, because i'm not a self-salesman, i'm a software engineer [that's my look-out, nobody else's]. but, other people stepped up to the plate (in some cases by greedily pushing me aside and then privately regretting having done so).

anyway - all i'm saying is: they could have done a much better job, much quicker (a decade quicker), if they'd actually listened to my advice, and worked together instead of working to push me out and try to "take over".

Re:2002 (1)

Anonymous Coward | about 2 years ago | (#40230847)

why is it that everything you say makes you come off as batshit, even the way you name drop luke howard in every one of your posts smacks of mental instability

are you angry some dude nobody here knows about or cares about made it rich while you're still a nobody living alone?

Re:2002 (0)

Anonymous Coward | about 2 years ago | (#40230875)

Been there. Done that. Not with SAMBA, but with lots of other technologies. The ability for people to be selfish, closed minded, egotistical, and extremely near sighted should never be under estimated. And pointing this out, even politely, usually brings out arrogant pricks about how "I'm wrong", or "not possible", am foolish to "not have created a business around it and/or made a couple million....", so on and so on. In otherwords, the very small minded generally take offense and or become enranged with jellousy and somehow find means to justify an attack; no matter how politely worded.

Several things I've learned very clearly from life is that:
  o common sense does not exist - citing it is a fallback for the weak minded
  o life is not fair
  o by far, the majority of people are NOT inherently good at heart - they are selfish, selfish, selfish, and extremely self serving
  o excessive political correctness has become a shield of those who refuse to learn to cope and deal with people - which is not to say politeness has no place. On the contrary, politeness is generally lacking, but that's different from political correctness. Its sad they are frequently conflated; which is another sign of the weak minded.

Re:2002 (2)

bill_mcgonigle (4333) | about 2 years ago | (#40231521)

luke howard *did* do it [the equivalent of a version 2.0]. he *did* release the product [in 2002]... and he had to hold out for 8 years for a decent offer of a buy-out. everyone kept offering him stupid-money ($100k or less).

Serious question - why did I never hear of this? Either it didn't really work, it was the worst marketing job of all time, or it wasn't really open source.

that's why luke howard's work was successful, so quickly, because he leveraged the best available work in the most efficient and least disruptive way possible.

And every Unix nerd would have recognized this as the right approach and deployed it, if it spec'ed as per above. Something you're not telling us?

Re:2002 (4, Insightful)

Sycraft-fu (314770) | about 2 years ago | (#40230761)

"You're a fool if you're telling the truth"

I'm sure he's not. He probably isn't outright lying, as in just making something up from scratch, but rather just suffering from Smartest Motherfucker in the Universe Syndrome, as many programmers do.

I see it all too often, programmers who seem to think they are god's gift to programming. They think they are WAY better than all the stupid "normal" programmers. They can't see why people have so many bugs, can't understand why development takes so long, can't understand why programmers don't "just make this happen," and so on.

Hence he probably did look at this and say "That'll be easy," not understanding the full complexity of implementing a really good AD server. The Samba team perhaps does understand and wasn't interested in playing around with someone who doesn't.

Re:2002 (1)

lkcl (517947) | about 2 years ago | (#40230779)

- while Kerberos might be paid lip-service by MS, their variants are quite different and not the kind of thing you want polluting an otherwise independent codebase.

you're not getting it. luke howard's patches to heimdal, samba and openldap were the order of like 100 to 200 lines of code, each. they "outsourced" the required network traffic to XAD's daemons or plugins. for example, to create the PAC, luke howard implemented a well-known DCE RFC which provides a service called "PAULAD" - plugin authentication something something you get the idea - and then plugged that in to both heimdal and openldap.

the differences are *not* big enough to go spending years writing an entire new kerberos server and an entire new ldap server. plus, who the hell's going to configure these "new" services?? who the bloody hell's going to integrate them with existing kerberos and openldap deployments? who's going to convert their entire kerberos and openldap infrastructure of two or more decades over to something untried and untested - exactly as you've pointed out!

each of the services (of which there are about 30) required for an NT Domains system is something like 5-10 man-years of development to properly and fully implement. to start throwing in an entire new kerberos implementation and an entire new ldap implementation _and_ an entire new DCE/RPC runtime (which is itself a multi-man-year development effort) is complete madness.

that's why luke howard's work was successful, so quickly, because he leveraged the best available work in the most efficient and least disruptive way possible.

Re:2002 (3, Interesting)

segedunum (883035) | about 2 years ago | (#40231029)

I've got to admit that the length of time Samba 4 has taken has left a bit of a bad taste in my mouth. Re-implementing all the required services in one package at a cost of many man-years never struck me as the greatest of brainwaves. Yes, there are a huge number of corner cases regarding exact compatibility but Samba 4 could have happened much faster and the drudgery of hard compatibility testing could have happened much, much sooner by reusing existing software.

As it is, Microsoft got Samba doing exactly what they wanted for the last ten plus years - pointless fire and motion, duck and covering - and the project has now become all but completely irrelevant. Samba 4 really needed to come out not long after the release of Windows XP. Those needing a Windows 2000 DC system gave up on waiting for Samba a long time ago. It might be moderately useful for those who have to use Linux systems in some fashion with Windows, although they will have found ways around that long ago, but the window of opportunity for Linux to replace Windows Server in a lot of places continuing the momentum of Samba 3 has been completely lost.

Re:2002 (0)

Anonymous Coward | about 2 years ago | (#40231369)

yeah nah, I wouldn't count your eggs yet on that assumption.

Lots of new startups happening with new sysadmins. if you get what i mean.

Re:2002 (0)

Anonymous Coward | about 2 years ago | (#40230587)

You're sadly misinformed about how this all works. Samba code is licensed under free and open licenses. Nobody can prevent you from forking it, from taking it or parts of it and using it in your own projects. Not the maintainers, not the team leaders, not the developers.

Re:2002 (1)

Anonymous Coward | about 2 years ago | (#40230721)

People can basically stop reading at

in essence the samba team leaders felt threatened by my abilities, and did not wish me to become the technical lead [by default].

...thats when it's obvious this is nothing more than some bitter rant. Looking at your website, your 'genius' is quite obvious. Nobody wants you and your abilities, get over it.

Re:2002 (0)

Anonymous Coward | about 2 years ago | (#40230781)

Why is this drivel modded up? For starters, why would anyone implement an ldap, dce/rpc, etc from scratch? Stable and mature projects exist for these, why reinvent the wheel, it's time spent poorly. That very notion is why nobody should give you technical lead on anything worthwhile, you would make poor decisions. Secondly, you clearly don't get open source development. It isn't about ascending some figment-of-your-imagination job title or dick waving. Just help, commit, fork, repeat. If you felt strongly about AD support in 2002, you could have submitted patches, or forked your own samba-blah and implemented it. Anything else is just unwarranted self importance and arrogance. In short:

Dear Sir,

You are an untalented nobody and a nutter.

Signed,
AC

Current Samba3-as-domain-controller user here (4, Interesting)

Anonymous Coward | about 2 years ago | (#40230327)

So, I guess our organisation is one of those strange ones that persists with Samba as a domain controller.

To date, we have around 400 machines (desktops and laptops) running mainly XP (but some with Windows 7 and with a full migration in progress to Windows 7). We run two separate Samba 3 DCs to service out two domains. This setup has served us well for almost 10 years now.

The main challenge presented to someone trying to run Windows Vista or above on computers attached to a Samba3 domain controller is the lack of group policy options. With XP and below, you can use the 'ntconfig.pol' method to deploy policies to workstations on the domain. With Vista (and Windows 7) this method is no longer supported (and I don't just mean 'not officially supported, but works with some hacks'- it actually does.not.work.at.all). There are ways around this, and I have managed to find a workable solution that will allow us to run Windows 7 exclusively on a Samba3 domain and still have basically the same policy options available to us (this is achieved by working on the local computer policy for non-administrator users on the master image of our standard operating environment, combined with manually mapping samba groups to certain local groups on the workstation). This obviously isn't perfect, but it works for us and saves us a heck of a lot of money compared to the alternative, but I appreciate that what works for us won't work for everyone.

So for me, the major feature that Samba4 brings to the table is the group policy side of things (I know there's obviously a lot more to it than that, but at present that is the major thing that feels 'missing' from Samba3). Given that I see no reason why we won't end up sticking with Windows 7 until it ends extended support (in 8 years time) I see no reason why we won't be using Samba for quite some time.

Oh, and other than congratulate the Samba4 team in general, I have to give a personal congrats to Andrew Bartlett- a fellow Aussie and someone I have met personally. Thanks for all your hard work guys!

Who cares. (0)

Anonymous Coward | about 2 years ago | (#40230467)

I mean seriously ... who cares. If you are deploying an enterprise class infrastructure get yourself a couple Win2K8R2 VMs and move on. I loved Samba a decade ago ... it allowed me to avoid M$ products. These days Samba is just one big bug. I don't have the time nor energy to battle it.

Re:Who cares. (0)

Anonymous Coward | about 2 years ago | (#40230619)

There's no less reason to avoid MS products now as there has ever been. You think it's suddenly become open or free?

Samba works great for many, and samba4 is actually being used in production in places, despite the beta tag. If you have to "battle it", then you do not understand how to use it, and you need to improve your skills or hire a competent administrator.

Harsh (2, Interesting)

AdmV0rl0n (98366) | about 2 years ago | (#40230575)

SAMBA-nice, has its uses.
But if you want to do AD, do it with MS. Don't pretend that it can be done with SAMBA (at least not without pain). At the very least, SAMBA trades its own mad ranting about being interoperable while setting everything internally so its not.

And bottom line, the squeeling, crying and whining about MS interoperability never struck a cord at all with me. SAMBA came about because open source and its structures offered nothing that came close. If Novell and MS can offer a client and a back end server, it seems to me that Linux and open source could have providided a best of breed method of its own.

Instead, all I ever saw was that MS was evil and Linux and open source had to be given access to it. To my mind this was nothing much more than legally enforced theft of technology and I never thought it was right.

Several years later - and having had access to all they wanted, this is where we are?
Given the fuss kicked up, and the legal demands, I think MS should turn round and issue a counter case and state 'where is the interoperable product people put us through a legal case for?' You said we were the case of the failure of this in the market place, we complied and where is the product?

And no, don't get me wrong, I really like open source, and I like Samba and so on, but I never liked or thought that legal case had any merit, and I never thought open source really got its shit together in providing anything, it just seemed to want to steal someone else's work in this particular area.

Re:Harsh (3, Informative)

ratboy666 (104074) | about 2 years ago | (#40230749)

"it (open source) just seemed to want to steal someone else's work in this particular area."

What a baddass comment. Completely wrong, of course, but badass.

SAMBA predates Windows SMB server.

It would be just as accurate to say Microsoft "just seemed to want to steal someone else's work in this particular area."

Re:Harsh (0)

Anonymous Coward | about 2 years ago | (#40231175)

Awful lot of misinformed Microsoft shills out spreading FUD.

Too bad you're so hilariously wrong that it's easy to spot you. Try educating yourself even just a tiny little bit before you troll, next time.

What about LDAP (2)

ulzeraj (1009869) | about 2 years ago | (#40230851)

I've tested alpha 16 and 18 and they are quite functional. I just wish they took the external LDAP route. Running on top of LDAP is good but being restricted to their own internal LDAP server isn't.

Right now if you check their wiki they discourage the use of an external LDAP server. So while they offer scripts to migrate your Samba 3.x LDAP based directory what should I do about the other applications using my directory server? Can I extend the schema? Their default setup doesn't even have the Posix schema attributed to nis.schema.

Re:What about LDAP (2)

robmv (855035) | about 2 years ago | (#40231395)

I am not sure about the current status of the work of the Red Hat team behind FreeIPA, that integrate Samba 4 with other FreeIPA base technologies like 389 LDAP Server (I remember Simo Sorce was working in Samba integration), there is outdated documentation about using Samba 4 alphas with 389 LDAP server backed [freeipa.org] , so there is interest in that kind of integration

Tools (1)

Anonymous Coward | about 2 years ago | (#40231075)

Just hope the tools that now allow slightly easier admin of Samba start looking at Samba4 now. Ok we are all CLI people at heart, but to move over the admins who just want to open AD tools and change a user, it would be useful.

This is a immense thing to appear and will help moving some offices over to not use M$ AD. Only problem is all the other tech that M$ pile on that you end up relying on. If its just AD and file, you are fine. But if you want to do Exchange, sharepoint and MS SQL, migration will definitely take longer! Not its impossible, there are some great alternatives, but just takes longer.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...