Some suggestions for samba-packs:

Server:
samba-common
samba

Client:
smbclient
(smb4k)


Webinterface:
swat
(inetd)

Additional:
fusesmb
fuse-utils
libsmbclient-dev
libfuse-dev
winbind


samba-doc
samba-doc-pdf
tdb-tools

komba2
smb4k

Please discuss, change, add or delete some stuff.

Greez w.
Back to top

Not a bad list to start, though I think the doc stuff could probably be skipped, seems like this could work:

basic server
advanced server

basic client
advanced client

What i see happening based on your list ideas is slightly different than my first idea, which was one section, now it seems more logical to have one master controller, with primary categories, samba, apache, nfs, etc, each leading to more options.

i've started to catch up on some stuff, and I also started cleaning package install file to get it ready to do more work on, I just finished that a few days ago.
Back to top

Hi

My evil brain helping you plot the overtaking of the world with the bestest script in the Debian world...has another cunning idea??

Some of us in Australia and other parts have ISP bandwith download counting plans....the more we download the more we pay or the slower we get....so just an idea for your consideration is this

In the script...which works beautifully to update the kernel...the next part of the update is ...the smxi script automatically starts to download or check for updates to modules for the new kernel.

1) I was wondering if you could consider posing a question ...for each module to be checked....similar to the remove module section that you have in the other options....so the user can decide to NOT download any module that they know they do not not use.

I would imagine others may berate me....for some people may not run lsmod...or know their hardware or software and so may increase false positive errors because they have refused to download a NECESSARY module.

So you may need to put a disclaimer or warning in that section?

2) I see the long term benefits as:
-Debian Mirrors not being hit to downloading un-necessary stuff
- users saving some dollars or not hitting their SHAPING limits earlier
- all internet having a slightly reduced data movement helping all users including those poor ms souls

submitted for your kind consideration.

I apologise for emphasis in using upper case.
Back to top

Those modules are miniscule, for latest 32 bit kernel, for example, all the modules have a total size of 532 kBytes, about the size of 5 bloated web pages that is.

However, look on the bright side, the pages of techpatterns.com, and to a lesser extent, smxi.org, are radically optimized, and save you about 6 to 10x what a visit to say, sidux.com forums, would cost you in bandwidth.
Back to top

h2

forgive me.

I am unworthy and shall lash myself severely


cheerio
Back to top

aus9,

You're funny. I like that.
Back to top

Don't know how feasable this is. For me, the first thing I do is hit init 3 and run smxi with any new installation. I reinstall frequently due to my own corruption of files and cruft accumulation while trying to improve the fluxbox experience for myself and a few others.

Anyway, what I would like to see in smxi would be two or three different versions of /etc/sysctl.conf

maybe one that just deals with network settings, and one that might have tweaks for either desktop or server functions. i.e adding:
vm.swappiness = 10 (or 0, or whatever you think may be best as an option)
vm.vfs_cache_pressure = 50, and any other simple ones for desktop or server use. (are there others that are good defaults to add?)

Even if these were just 'add as desired', I think it would be a cool addition. Don't know about the feasability of this though. This is one of only a few core changes I need to make to a newly installed system after running smxi.

Also, did I notice the script handling the modules a bit different? didn't have to wait long after a new kernel install :)
I don't know much about code yet, but I know a lot about hard work. Your dedication to helping others is admirable.
Back to top

Anything as specific as user settings in /etc like this are best handled with a custom user script, which can be stored on any webserver, then added to the post du options automatically via: smxi -X scriptname#script-download-url

See smxi options for sample use of -X option in smxi.

Basically, you can launch any script at all like that, ideally you setup an account somewhere like dyndns.org, then pick a domain name you can remember, then just create a link to the url the file is stored on.

If you're running apache, it can also be stored in localhost, but that wouldn't help on an initial setup.

All you need to do in this case is create a list of sed commands that update the stuff to what you want it to be whereever you want.

Ideally, at some point people will start to create modules for new functions, then once they are heavily tested and robust, ie, they work on every computer they run on, not just your's, and do what all users would want, or enough to warrant including it in smxi proper as a new module or a new feature of an existing module.
Back to top

Thank you for the tip. Looks like a good solution and easily implemented.

I had the cart before the horse. I'll be studying ways to use your script more efficiently. It sounds as though your smxi script has use for all sorts of things.

I'm just now beginning to understand how scripts work and the potential behind them. I've made a few simple bash scripts to control mplayer and conky, and have changed others to suit my needs. Also started to look at 'dialog' and 'zenity'.

Would you suggest another program I should look at? I learn best by taking something apart rather than studying the book.
Back to top

bash is pretty easy, I dislike dialogue and zenity, and consider them just bad hacks that aren't very useful, which is why smxi is not using them at all. smxi has a lot of options few people are aware of, most of which I've added to help any future potential contributors use it for testing and development.

Read the script documentation for more ideas of what you can do re testing and development.

Personally, I find most bash stuff out there very poorly written, like most perl stuff, and not at all a good example to follow, because of some perverse pride bash and perl scripters seem to take in writing what is correctly called 'write only' code, ie, code that cannot be understood, maintained, or modified.

I had to rewrite smxi and related scripts a few times as I began to realize that the supposedly 'good practices' many bash sites show were actually just what they appeared to be: bad programming practices.

Basically, just look for well structured, easy to read code, to learn from, that's what I did years ago when I was lucky to come across early phpbb stuff, which, for all its flaws, is well written code.

start with clear, easy to identify variable names, use functions, like building blocks, and your code will benefit massively.

See the various svn stuff for samples, listed at smxi.org home page, especially note the simple back end scripts for smxi, usl, dsl, and xsl. Those are very small, simple, but show the benefits of using structured, readable code, even with very short scripts.
Back to top