davidrg wrote on 2022-04-20, 23:14:

twiz11 wrote on 2022-04-20, 22:45:

elvis wrote on 2022-04-15, 08:05:

IPX is still on my to-do list for RetroNAS. But I've got some nagging networking stuff I want to get out the door first - a basic LAN segmenter with firewall and DHCP server, and some PPP over serial stuff.

IPX/SPX, my days of using Novell Netware have served me well, considering how I was able to get a LAN going in Age of Empires 2. Nowadays it seems IPX/SPX is relegated to DOSBox.

Still pretty good for network drives on real DOS machines - the client (including NIC driver) uses less conventional/upper memory than EtherDFS leaving more for games or other TSRs while also giving you an IPX (and TCP/IP) stack for free if you want to play LAN games. Don't know what performance is like but I doubt it would be worse than the alternatives (EtherDFS, SMB). Its also perhaps the only option for OS/2 unless you have any of the special IBM network add-on bits which, prior to Warp 4, were sold separately (1.x, 2.x) or only included in the special Connect edition (Warp 3). Though I doubt OS/2 networking is relevant to many people, especially on "old" versions.

I keep finding myself stuck in the past

Awesome project. I've spun up a Debian 11 LXC just for this. I am a bit stuck though, trying to mount my fileserver (CIFS) via /etc/fstab, but it just doesn't want to work, no error messages while mounting, but the mount isn't working. I'm doing the exact same thing in another VM (Ubuntu Server). Is this not supported or am I doing something wrong? Couldn't find any mention anywhere regarding this sort of setup.

//192.168.1.11/software/games /mnt/retronas cifs uid=1000,gid=1000,credentials=/home/.smbcredentials,iocharset=utf8,sec=ntlmv2,noauto,x-systemd.automount,x-systemd.idle-timeout=5min,vers=3.0 0 0

EDIT: NFS gives me an error when trying to link via cockpit: "mount.nfs: Operation not permitted"

Sp33dFr34k wrote on 2022-04-21, 12:55:

//192.168.1.11/software/games /mnt/retronas cifs uid=1000,gid=1000,credentials=/home/.smbcredentials,iocharset=utf8,sec=ntlmv2,noauto,x-systemd.automount,x-systemd.idle-timeout=5min,vers=3.0 0 0

Test this on the command line with "mount -t cifs blah" first. That'll give you verbose output on what's not working before you throw it in fstab.

Sp33dFr34k wrote on 2022-04-21, 12:55:

EDIT: NFS gives me an error when trying to link via cockpit: "mount.nfs: Operation not permitted"

Same here. Mount on the command line first to see what's going on. Throwing it straight into config files is time consuming because (a) you probably won't boot properly (pro tip: autofs is better than fstab for this reason), and (b) your logs will get buried in syslog/dmesg.

Try on the command line first to iron out your site-specific configs, then when that's working transfer it to boot time config files.

elvis wrote on 2022-04-22, 00:14:

Test this on the command line with "mount -t cifs blah" first. That'll give you verbose output on what's not working before you […]
Show full quote

Sp33dFr34k wrote on 2022-04-21, 12:55:

//192.168.1.11/software/games /mnt/retronas cifs uid=1000,gid=1000,credentials=/home/.smbcredentials,iocharset=utf8,sec=ntlmv2,noauto,x-systemd.automount,x-systemd.idle-timeout=5min,vers=3.0 0 0

Test this on the command line with "mount -t cifs blah" first. That'll give you verbose output on what's not working before you throw it in fstab.

Sp33dFr34k wrote on 2022-04-21, 12:55:

EDIT: NFS gives me an error when trying to link via cockpit: "mount.nfs: Operation not permitted"

Same here. Mount on the command line first to see what's going on. Throwing it straight into config files is time consuming because (a) you probably won't boot properly (pro tip: autofs is better than fstab for this reason), and (b) your logs will get buried in syslog/dmesg.

Try on the command line first to iron out your site-specific configs, then when that's working transfer it to boot time config files.

Thanks, I figured it out. First off, I was using an unprivileged LXC, which wasn't helpful. Fixed that and got some errors when trying to mount from the command line. Fixed that, but still didn't automount via fstab. In the end it seems like it doesn't like noauto and systemd.automount, so I left those off. Weird, because it works fine in Ubuntu Server, which is a Debian derivative. Anyways, now I can continue checking your software out, thanks again 😀

Well, looks like it finally happened .
The current Samba version on my Debian OpenMediaVault install does not like Windows 98SE clients .
It doesn't even log connection attempts .
Any suggestions before I start putzing around with Docker or Podman ?

Running :
apt list --installed | egrep -i samb

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

python3-samba/stable,stable-security,now 2:4.13.13+dfsg-1~deb11u5 amd64 [installed,automatic]
samba-common-bin/stable,stable-security,now 2:4.13.13+dfsg-1~deb11u5 amd64 [installed,automatic]
samba-common/stable,stable-security,now 2:4.13.13+dfsg-1~deb11u5 all [installed]
samba-libs/stable,stable-security,now 2:4.13.13+dfsg-1~deb11u5 amd64 [installed]
samba-vfs-modules/stable,stable-security,now 2:4.13.13+dfsg-1~deb11u5 amd64 [installed]
samba/stable,stable-security,now 2:4.13.13+dfsg-1~deb11u5 amd64 [installed,automatic]

Conf file additions :
min receivefile size = 16384
getwd cache = yes
write cache size = 524288
security = user
ntlm auth = ntlmv1-permitted
server min protocol = LANMAN1
lanman auth = Yes
client lanman auth = Yes
client plaintext auth = Yes
map to guest = Bad User
guest account = nobody
client ipc min protocol = LANMAN1
client min protocol = LANMAN1

elvis wrote on 2022-02-04, 22:41:

Future plans are to use RetroNAS as a firewall of sorts. The current idea is: […]
Show full quote

Shreddoc wrote on 2022-02-04, 01:35:

D'oh! I mean, asking for a friend : what does managing old computers inside modern networks involve?

Future plans are to use RetroNAS as a firewall of sorts. The current idea is:

RetroNAS will run dnsmasq (small DNS/DHCP tool) on the device itself, to configure all IP level stuff into a separate network. User then defines their modern and retro network interfaces, firewall scripts run to optionally allow retro computers to get out to the Internet (that'll be a yes/no question), but not allow them to see your modern network.

Likewise the modern network can get to the RetroNAS device itself, but not to machines sitting behind it. That then at least network-isolates the two sides, but allows RetroNAS to serve as a file drop in the middle. So a scenario like "download a file from archive.org/github/whatever on your modern computer, put it on RetroNAS, walk to old computer and it's waiting on the network mount" works somewhat securely.

Still in planning phases, but that's the goal. I've got a few other things to get through first as there's been a huge feature request list come in this week.

In general good news, I picked up a contributor who's already doing amazing things. "tcpser" is a tool I'd never heard of, and turns your RetroNAS into a Hayes-compatible dialler. You can't get full Internet browsing (pppd and DreamPi will do that eventually, I'll try and work on both soon), but you can use it to connect to public Internet/IP-based BBSes via ADT commands from loads of old computers (DOS, C64, Amiga, etc). He's working on that and sent me some screenshots of it in action, looks really cool.

I'm guessing EtherDFS is going to have a somewhat lethal reaction to VLANs. If so, that makes Pi on a stick configurations a no-go zone in general.

gdjacobs wrote on 2022-10-10, 02:33:

I'm guessing EtherDFS is going to have a somewhat lethal reaction to VLANs. If so, that makes Pi on a stick configurations a no-go zone in general.

It should be fine. EtherDFS can live in the "retro zone" on the same layer-2 network as everything else. That means it can see and mount RetroNAS itself no problems.

Your modern network would live in the "modern zone", and optionally be firewalled based on rules you want to apply. So, for example, you could allow TCP/445 and TCP/22 inbound for SMB2+ and SSH respectively, but block everything else (including RetroNAS getting back to your modern network for unrelated requests outside of the mentioned protocols). That gives you some protections on your modern network from any retro protocol nasties (unecrypted protocols, various SMB1 flaws, etc) but still would let you use RetroNAS as a drop-box between your modern and retro networks.

Speaking of drop-boxes, I'm mucking about with rclone and various cloud based mounts. Very possible to mount up cloud services like Google Drive, Microsoft OneDrive, DropBox, and a variety of S3 suppliers, and have them all re-exported over RetroNAS with legacy protocols to your retro computers. Mounting something like Google Drive from your DOS, Classic MacOS or Windows 95 machines is entirely possible. There's some complexity to this currently, but I'd like to at least get the tools in place and some documentation working for that too.

Yep, everything works fine with VLANs. I've had a "retro zone" as elvis explains for many years now, historically with a physical Windows Server 2003 R2 machine hosting everything, and now virtual on a TrueNAS SCALE host. I've been kicking the tires though on RetroNAS, and EtherDFS is definitely preferable from a memory footprint standpoint on the clients vs SMB. The way I have this setup is just such that it is managed by the switch, and so the clients don't have to have any knowledge of the VLAN and/or tag the packets etc.

It is a bit of setup work upfront, but then you've got a segmented network for as much retro network adventuring as you want, with little concern that you're going to risk your modern devices.

doogie wrote on 2022-10-10, 18:39:

Yep, everything works fine with VLANs. I've had a "retro zone" as elvis explains for many years now, historically with a physical Windows Server 2003 R2 machine hosting everything, and now virtual on a TrueNAS SCALE host. I've been kicking the tires though on RetroNAS, and EtherDFS is definitely preferable from a memory footprint standpoint on the clients vs SMB. The way I have this setup is just such that it is managed by the switch, and so the clients don't have to have any knowledge of the VLAN and/or tag the packets etc.

It is a bit of setup work upfront, but then you've got a segmented network for as much retro network adventuring as you want, with little concern that you're going to risk your modern devices.

That sounds fantastic!