Help with dotpup.sh file for Samba-server.pup (SOLVED)

[sunburnt]

The Samba-server.pup package installed (went through the compile process) on PizzaPup105.
But I wasn't sure if it worked as it was already installed, but it didn't mess up the current install.
Now that I've got EmptyCrust running to build PupServer on, I tried installing it and it did nothing.

This DotPup isn't a simple one as it compiles & then installs Samba.
Maybe precompiled for the DotPup would be better (it might end up bigger or smaller)?
Anyway... if one of you DotPup gurus would be willing to take a look at it, it can be fixed I'm sure.

#!/bin/bash
########### This DotPup compiles & installs the full Samba package from source.

F="samba-3.0.21b.tar.gz" # get just source file name
FX="samba-3.0.21b" # get just file name, no: .tar.gz
TMPDRIVE="home" # home or sda1 or other drive with write-acess
#TMPDRIVE="sda1"

# check for the usr_devx.sfs file in: "/mnt/home" and in: "/"
if [ ! -e "/mnt/home/usr_devx.sfs" ] && [ ! -e "/usr_devx.sfs" ]; then
E="
####### ERROR: usr_devx.sfs file is needed to comple source programs!

FIRST you need to get and install the file: usr_devx.sfs

Download it here: ftp://ibiblio.org/pub/linux/distributions/puppylinux/

Then put it into the dir. /mnt/home

"
fi

# check for enough space in the /root dir. to unzip the dotpup files
RUI=`df /root | grep -i "/root"`
ROOTFREE=`echo $RUI | cut -d" " -f4`

if [ "$ROOTFREE" -lt 18432 ]; then
E=$E"
##### ERROR: not enough space in the /root dir. for the DotPup files!

You'll have to clear at least 18MB of space in the dir. /root

"
fi

# check for enough disk space on $TMPDRIVE to make the work image file
DUI=`df /mnt/$TMPDRIVE | grep -i "/mnt/$TMPDRIVE"`
DISKFREE=`echo $DUI | cut -d" " -f4`

if [ "$DISKFREE" -lt 65536 ]; then
E=$E"
##### ERROR: not enough space on the HOME drive for the Samba files!

You'll have to clear at least 64MB of space in /mnt/home

"
fi

if [ "$E" != "" ]; then # if errors, show a message box
xmessage -center "$E
########## Click [okay] to exit the DotPup installer. ##########
"
exit 0;
fi

xmessage -center "
================== Puppy Linux - SAMBA Server ==================


This DotPup compiles & installs the FULL Samba-3.0.21b package.

Credits:
duke93535 for the compile instructions & testing.
MU for script code and error checking.
sunburnt for script code and dotpup build.


Click [okay] to install Samba, it can take up to 20 minutes.
==============================================================
"
################################# this is test code
# xmessage -center "
# >>>>>>> test code <<<<<<<
#
# F = $F
# FX = $FX
# TMPDRIVE = $TMPDRIVE
# ROOTFREE = $ROOTFREE
# DISKFREE = $DISKFREE
#"
#exit 0;
###################################################

dd if=/dev/zero of=/mnt/$TMPDRIVE/SMBworkIMG bs=1k count=65536 # make a 64MB image work file
mke2fs -F -m 0 -b 1024 /mnt/$TMPDRIVE/SMBworkIMG # make a ext2 file sys. on it
mkdir /mnt/$TMPDRIVE/SMBinstallTMP
sync
mount -o loop /mnt/$TMPDRIVE/SMBworkIMG /mnt/$TMPDRIVE/SMBinstallTMP # mount work image
cp $F /mnt/$TMPDRIVE/SMBinstallTMP # copy Samba file to the work image
cd /mnt/$TMPDRIVE/SMBinstallTMP
tar -xzvf /mnt/$TMPDRIVE/SMBinstallTMP/$F # expand Samba source file
cd /mnt/$TMPDRIVE/SMBinstallTMP/$FX/source # change into Samba source dir.
./configure --prefix=/usr # configure, compile, & install
make
make install
cp /etc/samba/smb.conf /etc/samba/private # backup smb.conf file
ln -s /root/.etc/samba/smb.conf /usr/lib/smb.conf # make link to smb.conf in /usr/lib
if [ "`grep "# Start Samba" /etc/rc.d/rc.local`" == "" ] ; then
echo "# Start samba" >> /etc/rc.d/rc.local # add Samba start command to rc.local
echo "/usr/sbin/smbd | nmbd" >> /etc/rc.d/rc.local
fi
cd ~ # CLEANUP
umount /mnt/$TMPDRIVE/SMBinstallTMP
rm -rf /mnt/$TMPDRIVE/SMBinstallTMP
rm -f /mnt/SMBworkIMG
xmessage -center "
##### The full Samba package has been compiled and installed. #####


##### You need to edit the Samba file: /etc/samba/smb.conf #####

##### It has examples in it & there's Samba docs in: /usr/doc #####
"

[MU]

if [ "$ROOTFREE" -lt 18432 ]; then
must be
if [ $ROOTFREE -lt 18432 ]; then

and
if [ "$DISKFREE" -lt 65536 ]; then
must be
if [ $DISKFREE -lt 65536 ]; then

The reason:
"" is used to compare strings (characters).
Like
if [ "$HOME" == "/root" ];...
But you want to calculate numbers.
"$ROOTFREE" will be a string. If you use it in a mathematical comparison, it is converted to the number 1 I think.

If I change these lines, the diskimage is created, and samba starts to compile.

But then I get:

Compiling smbd/trans2.c
smbd/trans2.o: No space left on device
/tmp/ccYwGvzk.s: Assembler messages:

So it seems the diskimage is too small.

Mark

[sunburnt]

MU; Yes dang it, I knew that... just couldn't see it (the "" on the integers thing).
I ran dotpup.sh after fixing it & making the work image 96MB, it still ran out of room.
I upped the size to 128MB & thought I'd run the DotPup file this time instead.
I get the dotpup message that the package is OK, I click [okay] & nothing happens.
It would seem that it's not running the dotpup.sh file, I did: ls -l & it says:
-rwxr-xr-x 1 root root 3774 Feb 24 00:53 dotpup.sh
So it's executable, but the root root part may need changing, maybe a chmod 755 or something.
Other than that the file works by itself, but the DotPup doesn't.
I'm going to wait till it's fixed before trying to install again, so the DotPup can be tested.

[sunburnt]

QUESTION; If I run the commands:

./configure --prefix=/usr
make

Will I have a binary setup of Samba? ....... And where will the files be at?
Then have the DotPup package run:

make install

And this will install Samba into Puppy? I'm clueless about Linux style compiling.
This way the Puppy PC it's being installed to doesn't need to have the usr_devx.sfs file on it.

[MU]

jmarsden once posted a shellscript, to create a dotpup from .tar.gz -sources.
I minimally modified it, I attach it to this post.

Extract, run
./dpupmaker.sh /pathToFile/samba-3.0.21b.tar.gz

This installs samba, and creates a Dotpup of it.
You can give thisDotpup to other users then, it has the samba-binaries.

Attention:
If the Dotpup overwrites symlinks like /usr/share/pixmaps , Puppy gets broken.
So extract it manually first, and check the directory-structure carefully!

The script extracts the archive, runs
./configure --prefix=/usr
make
make install

Then it checks, which files in Puppy have a new timestamp, and packs them to the Dotpup.

The Dotpup can be uninstalled with Pupget.
I modified it, so that it installs to /usr instead of /usr/local , beause /usr/local/lib is not in Puppys search-path.


jmarsden also created a similar script, that creates unleashed packages:
http://www.murga.org/~puppy/viewtopic.php?t=5447

Mark

[sunburnt]

Mark; I thought I'd tell you... the dpupmaker.sh script didn't work.

### I "DO NOT" expect you to start trying to fix it, you've done lots already.

In the 256MB work image: /mnt/work/samba-3021b with dpupmaker.sh & samba-3.0.21b.tar.gz in the dir., I ran:

# ./dpupmaker.sh /mnt/work/samba-3021b/samba-3.0.21b.tar.gz
./dpupmaker.sh: line 121: ./configure: No such file or directory
dpupmaker.sh: Error: Unable to configure application samba-3.0.21b
#

It extracted the samba tar ball, but that's it.
I'll keep messing around with it, I also have been trying to make a duplicate link finder script.

[jmarsden]

Mark; I thought I'd tell you... the dpupmaker.sh script didn't work.

The dpupmaker.sh script is designed to work only for "normal" source tarballs that have a configure script in the top level dir they unpack to. It is a convenience for developers, not a replacement for understanding what is going on, at all. I use it mostly when I want to build ten or twenty or fifty dotpups from source at once, hands-free, not when first exploring a new source tarball I want to build from. Sometimes you'll get lucky... but, especially for larger applications, taking a good look at the contents of the tarball first is always wise! The message you saw about the lack of ./configure is a fairly large clue as to what the issue is for building Samba, and how to fix it -- the script has the wrong curent directory at the time of issuing the ./configure command.

To enhance dpupmaker.sh so it can handle the (rather unique) Samba tarball approach of having the actual sources and configure script in a subdir named "source", you just need to add one simple line to the script just before the ./configure command:

Code: Select all

[ ! -x configure -a -x source/configure ] && cd source # For Samba

and edit the two occurrences of .. into $DIR near the end of the script.

Note: I'm at work... no easy access to a Puppy box right now... this minor enhancement definitely allows the ./configure to run... but I offer no guarantees that the result will be a working Samba dotpup, at all!

If I remember, when I get home I'll upload a revised version of the script. I'm also very open to contributions or suggested enhancements from others, especially if the changes allow it to work more generally without losing any of its current capabilities. It's good to know people are at least trying to use it

Oh, and samba-3.0.21c is now the current production release of Samba. I'd suggest using it rather than 3.0.21b.

Final question: why is this in "Cutting edge" rather than "Additional software"?

Hope this helps,

Jonathan

[sunburnt]

Thanks jmarsden; I posted when it failed, before I actually looked at it.
I saw the clue you spoke of & fixed it, & it worked till it ran out of space.
I took the liberty of modifying (mangling?) it by making your script GUI based with Xdialog.
Also making & working in a image file so it can work on a FAT partition.
I've automated quite a bit of it, image file sizing is rough as I can't estimate the space needed to compile, etc.
Left undone was MU's suggestion of checking for duplicate links so they're not copied over, thus breaking Puppy.
It would make a great utility tool for most general purpose use, I'm also making a GUI make & mount files tool.
Q; could the script be modded to compile & not install, but instead package the program?

I've learned alot looking at your code, & my understanding of "pure" Bash code has improved greatly (I think).
If you want to look at my improvements / bastardization of your work say so, & improve ANYTHING.

Maybe I'll do the new Samba, but maybe I'll wait for Puppy 2 to do it.
I thought Additional Software was for packages "known to work", not a repair discussion forum, this seemed the place.

[jmarsden]

I saw the clue you spoke of & fixed it, & it worked till it ran out of space.

Good. I can't do much in the script to give you more disk space

I took the liberty of modifying (mangling?) it by making your script GUI based with Xdialog.

OK, if that's what you need. I'd suggest some way to prevent that, so you can still get the automation / hands off capabilities when they are needed. Maybe a --interactive switch or something similar? At minimum, check for the existence of a non-empty $DISPLAY variable before using anything that requires an X Window System server.

Also making & working in a image file so it can work on a FAT partition. I've automated quite a bit of it, image file sizing is rough as I can't estimate the space needed to compile, etc.

Interesting idea, but I'm not sure it logically belongs in the same script? As written, dpupmaker will use whatever filesystem it is run on. It unpacks to and works in the current directory. So it might make more sense to write a new wrapper script (fatdpupmaker.sh or something?) that takes the same parameters as dpupmaker.sh , sets up whatever temp disk space is needed, cd's inside it, and then calls dpupmaker.sh to do the work? Might have to do a bit of path fixup so that a relative path to the source tarball works as expected, but other than that, it should be straightforward. Having one tool do one task is a very long-standing tradition in the Unix world.

Regarding sizing... assuming the loopback filesystem will be temporary and deleted on exit, and since Puppy is pretty much inherently single-user at the moment, you could just make the loopback file as large as you can -- use all free space in the FAT partition concerned? This might well be successful more often than trying to guess how much temporary work space a particular package will need? As long as you take care to really truly clean the thing up afterwards, even in the case of dpupmaker.sh failure underneath you... I don't see much of a downside to always using a big loopback fs? Reduced speed, maybe, if you have a huge and slow hard drive?! [/i]Imagine creating a 400GB filesystem just to compile some tiny 500k application... hmmm, maybe a way to specify a maximum fs size might be handy, but the default should be to work with more tarballs, and so should be the biggest fs you can create, I think. Not many Puppy developers forced to run in VFAT partitions have 400GB disks anyway... and if they do, surely they can spare a few GB of such a disk for an ext2 or ext3 partition

Left undone was MU's suggestion of checking for duplicate links so they're not copied over, thus breaking Puppy.

I'd like to see an example of a source tarball that breaks dpupmaker.sh first -- not a contrived one, a real source tarball for which this is an issue. Do you or MU know of one?

It would make a great utility tool for most general purpose use, I'm also making a GUI make & mount files tool.

I think there's a philosophy issue here... if you sort-of GUIfy the traditional command line software development tools, who are you helping? People who want to become Linux/Unix developers need to learn the command line tools anyway, or the first time the GUIfied setup (or dpupmaker.sh itself) breaks, they are totally stuck. Then they ask me for help, because my name is inside dpupmaker.sh ... or you, if your name is inside the GUIfied tools concerned. I'm not sure that's a good use of my time, fielding questions about compiling or installing things from so-called developers who have not yet learned to develop in the normal Linux/Unix command line world. It all too easily creates an unhealthy dependency on me, rather than teaching people to become developers themselves.

Q; could the script be modded to compile & not install, but instead package the program?

You have to install the compiled software somewhere before you know where the installed files go, and you need that info in order to package anything. It is often possible to install to a temp dir and work that way. RPM does this if you use its BuildRoot: directive in a .spec file, for example. But it is not always straightforward to persuade the normal "make install" to install somewhere other than the intended final destination (the one you set up in configure with --prefix and its relatives). So such a mod is possible, but might reduce the generality of the script (so it would probably then work on fewer source tarballs) if you made that the default. It's certainly a candidate for a future enhancement, if you think it would be useful.

If you want to look at my improvements / bastardization of your work say so, & improve ANYTHING.

I'd rather you improved your code, for now... when the improvements do not remove or lessen what dpupmaker.sh can do already, and (in the case of the loopback mount filesystem stuff) are appropriately modular, I'll take a look before you release your code on the general public, if you like.

I thought Additional Software was for packages "known to work", not a repair discussion forum, this seemed the place.

I suppose it depends on your definitions. A Samba dotpup already exists and was announced, so at some point someone must have thought it worked. And (within the limits of its intended users and 'pretty standard' source tarballs) dpupmaker.sh is definitely "known to work", or I'd not have released it But I see what you mean.

Jonathan

[sunburnt]

Gotcha, I'll check what all you said, & I'm making it command line as well as GUI.
I made the image file 10 times the size of the source file, it work for Samba & it's a large package, it should be good.
Haven't used it but this once for Samba, so don't know of anything that'll break it.
Yep, I figured the install commands/instructions would have to be followed to make an "after compile" install script.
If the binary build were put in a matching tree structure it'd easy, but I doubted it was done that way.

Thanks jmarsden

[sunburnt]

Well... I've been at it for days now, & I've got the Samba DotPup working sort of.
Sometimes it installs & works & then on another PC it won't, it's working on this PC now.
The latest build I made, upon samba start, it aborts, the files are all there, I can't see what's wrong.
None of the DotPup builds have started Samba, even though the command is in the dotpup.sh file.
Strangely it starts up 2 smbd daemons & 1 nmbd, I've never seen this before, but it still works.
I can kill one smbd & it keeps working (as I figured)... just plain WEARD!

[jmarsden]

http://www.murga.org/~puppy/viewtopic.php?t=5066 gets you the latestst dpupmaker.sh with the fix to allow it to compile Samba included.

sunburnt,

I suspect you've spent too much time on this...?

I grabbed the samba-3.0.21c.tar.gz tarball, and used dpupmaker.sh to compile it. Took a while to decide what configure options I wanted to use to get the files in what I would consider "normal" locations. Created a somewhat minimal rc.samba script and got it working. Noted that you need the samba account db to exist before samba works, so I added a check for that and use of smbpasswd -a to add the root user (with an empty password, BIG security risk!) if it doesn't exist. Left the Puppy-supplied smb.conf alone, even though I'm not really fond of it. Unzipped the dotpup, edited dotpup.sh to create and register the rc.samba script and then call it. Regenerate md5sum.txt and zip back up into dotpup form. Leave the dotpup on my HD where I can find it (not inside pup001).

Then I rebooted into RAM-only mode (boot menu option 4), mounted the HD partition concerned, use Rox to install the dotpup. Works as expected. Allowed connections from local LAN to relevant ports through Puppy firewall. Verified connectivty from Windows XP box (changed its workgroup to match the Puppy default of MYGROUP). OK (though it can take several minutes to become the local master browser). Booted back to usual (boot from CD, option 3, specify where the pup001 file is) mode, run samba that way. OK too.

Then used it to transfer the samba dotpup to a second Puppy box (HD option 2 install on PIII) (used smbclient \\\\1.2.3.4\\root -N to connect from Puppy console). Installed from dotpup. Tested access from other machines. Works.

I've not yet figured out LinNeighbourhood, but that's probably just me doing something silly?

samba-3.0.21c.pup is a large dotpup, approaching 17MB, because I trimmed nothing out of it -- but it is one that seems to work fine here on multiple machines. One evening's work. Should I upload it somewhere, or would you prefer to continue along your own development path?

Jonathan

[sunburnt]

Yes, I've spent 2 weeks learning I don't know enough about it to do a successful binary install build.
I've got the source install build working very well now, but your binary one doesn't need the usr_devx.sfs file.
I just wish that Samba wasn't such a tuff dotpup to build, a simpler one I probably could have done.
But PupServer needed it & there had been many posts about it over the last few months, it needed to be done.

LinNeighborhood acts weard at times, it would only show the host PC shares under another PC's mount.
Only rebooting both PCs & resetting everything up got LinNeighborhood working ok on the one PC again.
You have to [ADD] the remote PC & then double click to mount & view the share, works oddly & inconsistantly.

MU has agreed to host it, PM him & ask for his upload instructions.
Post back here & let me know when MU's hosting it so I can download it & install it to PupServer.
You'll want to put a post in Announcements so all will know it's working at last, gliezl was going to try it.
I'm sorry my inability has more or less forcing you to spend time building the dotpup... but many will rejoice!

Hopefully as you said, the binary install will be portable so PupServer will work when copied PC to PC.
I'm intending PupServer & LanPuppies to be "poormans" type installs, simple to setup & CD ready.
Now I can turn my full attention back to PupServer & LanPuppy & get a release version out.

Many Thanks Jonathan... for taking up the staff & finishing what I couldn't... Terry