Till smbv1 und netbios are disabled in Windows 10+ the samba shares were not discoverd by Windows. This script announces the samba shares so they were discoverd again. sources: https://github.com/christgau/wsdd https://manpages.debian.org/unstable/wsdd/wsdd.8.en.html It is only a python script an I testet it already. It works out of the box. What to do is to write a initscript or service to start it automatically. Within the script the "workgroup" and the interfaces which are to be used should be determined. Also we should use an unprivileged user and chroot it.
@Adolf: Would you like to take this one or are you currently busy with other things?
Hi @Michael, Yes, I will have a go at this. @Daniel will need to do any confirmation testing as I don't have any Windows systems on my network at all.
(In reply to Adolf Belka from comment #2) > Hi @Michael, > Yes, I will have a go at this. > > @Daniel will need to do any confirmation testing as I don't have any Windows > systems on my network at all. Daniel manually installed this on his system already and it works. We just need it packaging which is a thing that you do best :) But of course in the end it will need some testing. I think we should create this as an independent package with its own init script, but the package should become a dependency of samba since it is pretty much nonsensical to run samba without this unless you are still running Windows XP.
Hi ! can you explain how to start it up in ipfire ? Ciao Gerd (In reply to Daniel Weismüller from comment #0) > Till smbv1 und netbios are disabled in Windows 10+ the samba shares were not > discoverd by Windows. > > This script announces the samba shares so they were discoverd again. > > sources: > https://github.com/christgau/wsdd > https://manpages.debian.org/unstable/wsdd/wsdd.8.en.html > > It is only a python script an I testet it already. > It works out of the box. > > What to do is to write a initscript or service to start it automatically. > Within the script the "workgroup" and the interfaces which are to be used > should be determined. > > Also we should use an unprivileged user and chroot it.
(In reply to gerd from comment #4) > can you explain how to start it up in ipfire ? This is not available as a package for IPFire, yet.
Hi @Daniel We don't want wsdd to be looking at trying to use red0 so that means that the interfaces to be used should be specified. Should it only look at green0 or should it use green0, blue0 and/or orange0 if they are available as interfaces?
(In reply to Adolf Belka from comment #6) > Should it only look at green0 or should it use green0, blue0 and/or orange0 > if they are available as interfaces? Can we read this information from the samba configuration?
(In reply to Michael Tremer from comment #7) > (In reply to Adolf Belka from comment #6) > > Should it only look at green0 or should it use green0, blue0 and/or orange0 > > if they are available as interfaces? > > Can we read this information from the samba configuration? The answer is that an answer can be got from the samba global and smb.conf files. However samba.cgi places a fixed entry of interfaces green0 blue0 127.0.0.0/8 even if the IPFire instance only runs red and green - confirmed on a vm. The samba wiki indicates that only green0 should be enabled for security. Question now is what to do. My preference would be to change samba.cgi to interfaces green0 127.0.0.0/8 and make wsdd also only use green0. However that might give problems to people who have been using samba shares from blue0 since the change to a fixed green0 and blue0 entry was made in CU153 when the samba.cgi WUI page was tidied up and simplified with the change from samba3 to samba4. I might need to change the code in samba.cgi to only add in blue0 if the blue interface is actually present. Then the entry would match with the actual interfaces being used in IPFire but still limited to a maximum of green0 and blue0 which is what is defined today. Then that info could be used for wsdd to define if only green0 or both green0 and blue0 interfaces should be defined.
(In reply to Adolf Belka from comment #8) > (In reply to Michael Tremer from comment #7) > > (In reply to Adolf Belka from comment #6) > > > Should it only look at green0 or should it use green0, blue0 and/or orange0 > > > if they are available as interfaces? > > > > Can we read this information from the samba configuration? > > The answer is that an answer can be got from the samba global and smb.conf > files. I think I talked bollocks here... It seems that we have removed the option to enable samba on particular interfaces a long time ago... I suppose what we want to do is to enable wsdd on the same interfaces that samba is running on. > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=html/cgi-bin/samba.cgi;h=c60dca1d4804d723b7386367cfc3b2fd6c986d25;hb=HEAD#l795 This is hardcoded into smb.conf, but I suppose wsdd wants to know more precisely what interfaces there are, this is what I had in mind: > https://git.ipfire.org/?p=ipfire-2.x.git;a=blob;f=src/initscripts/packages/mdns-repeater;hb=HEAD > I might need to change the code in samba.cgi to only add in blue0 if the > blue interface is actually present. Then the entry would match with the > actual interfaces being used in IPFire but still limited to a maximum of > green0 and blue0 which is what is defined today. This would be even better. Jonatan proposed functions to check this very easily, but I do not think that ever made it into our code base.
I just tried out wsdd on a couple of vm's. One had only red and green and the other had red, green, blue and orange. I ran wsdd with verbose setting and specified both green0 and blue0 for the interfaces. On the red/green only system then it basically ignored the blue0 interface and recognised the green0 interface. On the four interfaces system it recognised bot the green0 and blue0 interfaces. So it seems to only do anything with the interfaces that are specified and are also present. However, I think it would be better to only specify the blue0 interface if it is present, so I will use the mdns-repeater addon to only include the blue0 interface in the samba.cgi code if it is present and therefore also only add it to the wsdd configuration if it is present. It just feels better for samba to only try and activate interfaces that are present and similarly for wsdd.
(In reply to Adolf Belka from comment #10) > It just feels better for samba to only try and activate interfaces that are > present and similarly for wsdd. That would definitely be a lot cleaner, but I believe that we had a lot of time pressure when we jumped onto samba 4, and so some of the shortcuts were never really straightened out again.
I have successfully added some code to samba so that the globals and smb.conf files only end up with blue0 in the interface line if blue0 is actually installed. I am now working on the initscript which is proving more challenging as running the wsdd initscript also starts wsdd as a pythion3 script so there are two wsdd pids defined for the two instances. pidof wsdd finds nothing and pidof python3 finds all the python3 scripts running. loadproc, killproc and status proc don't work as they depend on pidof finding the required pid and it comes back blank for the python script. Have tried alternatives to get the pid such as pgrep and filtering ps with grep and awk but both end up giving the answer I want when I run them as root from the console but give different pid values when run in the initscript. I am making progress on it but it is just taking a bit of time. A little bit of two steps forward and one step back. Will come back for help if I find that I can't make progress with the initscript.
I have successfully got the Start and Stop parts of the initscript working. I have successfully got a statement that extracts the pid of wsdd from the ps command. This has to be used as pidof does not work with wsdd. I then create the pidfile with the pid after wsdd has been started with the loadproc command and sleep for 5 secs. This might be able to be less but no sleep means that the pid is not yet available as the wsdd script has not fully started. 5 secs definitely works. Then running the killproc command with ip the pidfile I have created allows wsdd to be removed together with the pid file. Next step is to get status proc working. Unfortunately status proc does not have the option to use -p pidfile and so running statusproc comes back saying that wsdd is not running even when it is according to the ps command. I have some thoughts on how to overcome this. When this is all done with the initscript then I should be able to put everything together and do the build and test out the ipfire package that is produced to make sure that wsdd is actually installed and able to start and stop.
I have successfully got the status command on the initscript working so now start/status/stop are all working in the initscript and wsdd only sets itself up for blue0 if the blue interface is installed, same for samba. Will now do the build and test out the created .ipfire packages for the modified samba and the new wsdd.
That sounds really good. I could also test it if you want.
The build went fine and I have then installed the samba and wsdd .ipfire packages on a couple of vm systems on my testbed. One with only red and green and the other with all four interfaces. Everything went as expected on that. The one with only red and blue setup samba and wsdd with only the green0 interface. The other had both green0 and blue0 in the interfaces. The wsdd script is running and can be stopped or started and the status checked. Rebooting results in wsdd running. wsdd is set up to start after samba has started. The only thing I can't test is the check if the samba shares are seen by windows systems that are newer than version 7 as I don't have any windows systems available to me. The patch set was submitted at 14:30 today but there seems to be some delay with the mail system at the moment. They haven't shown up in the mailing list or in patchwork, although I got a copy of the patches when I ran git sendemail. @Daniel I will try and see if I can place the .ipfire packages into my git repo so you can access them and test it out with a windows system. It doesn't look like I can attach them to this bug as the patch type list does not include archive packages as an option. I will give it a try and see if it works but if not then I will look at how to get them into my git repo, if that is feasible.
Created attachment 1442 [details] The samba package file This attachment is the samba package file with the changes to apply the correct interfaces to the global and smb.conf files. Will see if I am able to attach an archive file or not with this
Created attachment 1443 [details] The wsdd package file This is the wsdd package file. The previous samba package file successfully uploaded so this is the best place to store them so you can test them together. Fingers crossed that everything works successfully.
Hi. I've downloaded and installed the pakfire files on my testsystem (IPFire 2.27 (x86_64) - Core-Update 182 Development Build: master/8064dce9). Samba is starting an runs as exspected. If I try to start wsdd it fails. [root@ipfire tmp]# /etc/init.d/wsdd start Starting wsdd daemon... Unknown Option: -b [ FAIL ] [root@ipfire tmp]# So I looked at the startscript /etc/init.d/wsdd and see that we try to start wsdd as followed. loadproc -b /usr/bin/wsdd -4 ${WSDD_USER} ${INTERFACES} ${WSDD_WORKGROUP} ${WSDD_CHROOT} It seems that on my machine loadproc didn't know the option -b I tried to start wsdd without the option -b and it starts but stays in the foreground.
(In reply to Daniel Weismüller from comment #19) > Hi. > I've downloaded and installed the pakfire files on my testsystem (IPFire > 2.27 (x86_64) - Core-Update 182 Development Build: master/8064dce9). > > Samba is starting an runs as exspected. > > If I try to start wsdd it fails. > > [root@ipfire tmp]# /etc/init.d/wsdd start > Starting wsdd daemon... > Unknown Option: -b > [ FAIL ] > [root@ipfire tmp]# > > So I looked at the startscript /etc/init.d/wsdd and see that we try to start > wsdd as followed. > > loadproc -b /usr/bin/wsdd -4 ${WSDD_USER} ${INTERFACES} ${WSDD_WORKGROUP} > ${WSDD_CHROOT} > > It seems that on my machine loadproc didn't know the option -b Check in your version of functions which is located at /etc/rc.d/init.d/ The loadproc function starts at line 418 and the option for -b (run in background) is at line 458. > > I tried to start wsdd without the option -b and it starts but stays in the > foreground. Yes without the -b it stays in the foreground and the initscript just stays there not moving to the next statement line. I also tried adding an & at the end of the line and that did put it into the background but then the loadproc does not end up showing the green OK for the start having been successful. The -b worked for me on my vm testbed system and it was running with CU182 I will go and have another look at my vm system tomorrow to confirm it is working. Not sure what could be causing that problem.
Patch set from @Michael that fixed the pid problem and tidied up and made secure the variables for wsdd has been merged into next (will be CU185). https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=bed265cc5ab80f97c4981f2ba5d4c1cb10c55f57 The ms/initscripts branch still needs to be merged. Patch set to make wsdd a dependency in samba and to stop and start wsdd when samba is started or stopped has been sent to the dev mailing list and patchwork. https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/IXAPJ5UA62EKO455QS3I3HTJO5K2ZL2Q/ https://patchwork.ipfire.org/project/ipfire/patch/20240229140937.15643-1-adolf.belka@ipfire.org/
Submitted additional patch set that integrates the wsdd initscript within the samba initscript and removes the wsdd initscript. https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/3RQOJYPLKWXM7ZDJQL7LIECEERKZ7X6J/ https://patchwork.ipfire.org/project/ipfire/list/?series=4228
Due to an error on my part I had not re-submitted a patch for adding wsdd as a dependency to samba. Found this out when running CU185 Testing. Patch now submitted. https://lists.ipfire.org/hyperkitty/list/development@lists.ipfire.org/thread/2ICIG26MPJTBBDABFZKE5OFBJ4PJBVUX/ https://patchwork.ipfire.org/project/ipfire/patch/20240325111752.9746-1-adolf.belka@ipfire.org/
That last patch has been merged. https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=cb0488997b9c2237058a0ff8c546c269b6a6f1ed
I have tested out updating from CU184 with samba installed to CU185 and the wsdd addition is now installed and starts and stops with samba. This is as far as I can test this update as I don't have any windows systems to be able to confirm that CU185 supplies the correct info. @Daniel, can you test this out to verify that it all works as expected in the Core Update.
https://www.ipfire.org/blog/ipfire-2-29-core-update-185-released