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
> 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
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
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