Am 17.06.2012 um 07:37 schrieb Rugxulo:
> Excellent details, even better if it actually works!   ;-)

I just can say that I had Debian 4 running quite a few years on several 486SX33 
with 20 MB RAM. Because the installation was the hardest part on such an old 
machine, I pulled out the drive on each of them and put it into a "more 
powerful machine" which had the advantage of having a CD drive. That worked 
well and I even compiled an own kernel for the 486 on it, with everything 
switched off that wasn't necessary. The "more powerful machine" was a Pentium 
200 MMX with 64 MB RAM. 

> But does Debian run on i386 [sic] anymore? I thought most people had
> (unfortunately) switched to i686 (CMOVxx), e.g. Fedora. Or is Debian
> more lenient??

Yes, Debian 6 dropped support for 386 CPUs, but supports everything from 486 
upwards (1). 

> Even if the cpu instructions themselves are compatible (no CMOVxx,
> which Pentium 1 lacks), you may not have enough RAM. I don't know for
> sure, but everything I had read always seemed to hint that a Pentium
> typically couldn't have more than 64 MB, so trying to cram a recent
> Debian might be a bit of a stretch, to say the least.

The "recommends" nowadays for the installer are 64 MB RAM (2). But it will 
still work with a minimum of 22 MB RAM (3). Of course you can only use the 
textmode installer and shouldn't install a GUI. 

> I have no idea of a better solution, unfortunately, only a blind guess
> that "maybe"?? Slackware 11.0 (circa 2006), aka ZipSlack, might work?
> At least it's easy to install atop DOS (kernel 2.4.x) and is "only" 67
> MB .ZIP'd. I'd assume it has lower RAM requirements. Though it's not a
> "full" install by any means, but you can add on any extras you need
> (supposedly).

You are right, if we talk about Linux, there are a lot of options. IMHO Debian 
stable has the advantage that it gets frequent security updates and that the 
simple commands "apt-get update" and "apt-get upgrade" makes it easy to keep it 

Of course it depends from the circumstances: If the machine can't be connected 
to the internet, getting security updates is harder but maybe not as necessary 
as with a connected machine.  A Linux server should be more secure than a DOS 
server but maybe this isn't necessary if the data isn't worth it.

> Well, hopefully everything Ulrich said will "just work" without
> worrying about all this extra stuff. Good luck!

Yes you are right :-/. These things can be harder than I wrote and there still 
may be difficulties. But I am quite happy that the Samba/MS Client connection 
worked for me as expected with a recent Debian and FreeDOS (and tested on real 
hardware). Of course if anybody wants to go on explore or correct things, you 
are welcome. For instance the socket options work for me, but I didn't really 
look into them, I got them from (4).

Nevertheless I am a bit proud to have even password authentication work fine - 
I did not get this to work in the past. Gerd Roethig with his smb.conf example 
(see 4 again) took the easy way out, as he dropped authentication at all. Of 
course if you add:

guest account = YOURUSERNAME

in the smb.conf global section and

public = yes
guest ok = yes

in the share definitions you get a system that is open to everybody and 
everybody has the rights of "YOURUSERNAME". But then we have even less security 
as with a DOS server, so what's the point?

What really helped me was this article in german language here (5).

I try to translate: The article explains that it may be NOT enough to set 

lanman auth=yes

in the smb.conf global section to allow authentication from old clients like MS 
Client, Lanman, WFW or Win9x. 

It will not work if you already have set a user and password BEFORE you added 
the above line to your smb.conf. This is very likely. To make lanman auth work, 
SAMBA needs to set a special password hash into its password database for that 
user. But it will not do that if the above line isn't present. You can check if 
the hash is set correctly if you type:

pdbedit -L -w i

on the Linux system. If you see a bunch of "X" in the third column (after the 
second ":") the hash is NOT set. The (easy) solution is to set the password for 
the user again by commanding:

sudo smbpasswd -a username

on the server. Another thing that is worth to explore further are the charset 
options of Samba. 

unix charset = ISO8859-15
dos charset = 850

makes sure that Samba shows filenames, that were created by the FreeDOS client, 
correctly back to the client. 
I use charset 850 because I live in Western Europe, others will want to use 437 

The contents of the files will not be corrected though. Debian internally runs 
with UTF-8, DOS with codepage 850 (or 437) so special characters will be shown 
differently in DOS and Linux. IMHO this shouldn't be a problem if the files are 
written by DOS clients only. 

All in all, I think it is a good to have proof that clients with FreeDOS and MS 
Client 3.0 can authenticate, read and write to a GNU/Linux Samba server. In my 
opinion such a scenario is a better idea than to run a server with MS Client, 
which was updated with a patch that is supposed for a different software (the 
DOS Workgroup Add-On).

Of course you could always just buy an old Novell Netware license from eBay.



Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
Freedos-user mailing list

Reply via email to