I guess I'm just not too sure how to get the web panel to handle different kinds of data. At the moment the setup is easy because it's just writing a full text file (like the loginscript rpm).
That totally depends on the wishes and plans you have with the contrib. But writing total files is a bad thing, as the templates normally should take care of that. Perhaps the loginscript is an exception because of the wide range of instructions that can be set, but for the purpose of generating configuration files as you seem to be doing, the template engine in combination with the database is the best and preferred way to go.
The only thing is that it's not necessarily going to be an ip. The contrib is an acl for squid that allocates a download quota for either ip, user (if squid_auth is setup), and a catchall)
That should not have to be a problem as you could easily store other types in your database, for instance host/ip and/or user. The templates then could cater for a catch all which you can define in your templates, but also in the database if you like.
there's also no set number of, umm trailing commands.
Ie I could have 192.168.1.50 5mb/day or even 192.168.1.50 5mb/day 2hr/day
I guess there is, somehow as I can not imagine that a user could have two limits for a day or a week, therefore the maximum number of parameters is limited to the number of limits you are defining, but my guess is the two major categories would be total amount of traffic allowed (in whatever unit of bytes) and the total amount of access time per period (which can be as finely grained as you would like it, e.g. mins/hr, hrs/day, days/week, weeks/month, months/year, but also seconds/year if you really desire. You could also opt to store the limit amount and the limit period in a different property, per key,for instance:
Limit = 10
LimitAmount = days
LimitPeriod = 1
LimitPeriodAmount = monthor:
Limit = 5
LimitAmount = Gb
LimitPeriod = 1
LimitPeriodAmount = year
or:
Limit = 3
LimitAmount = hrs
LimitPeriod = 1
LimitPeriodAmount = dayThe logic to generate the required rules should be in your templates. The database is only used to store the data so it can be retrieved from the database at the time the templates are expanded and the configuration files are being generated.
By using above approach you get a very clear and simple interface as the administrator only has to select four items to define the limits for the rule, two of them (the amounts) can be free text fields, the other two could be drop down lists to prevent administrators from entering data you can not handle or your templates do not support. The use of dropdown lists also prevent typos which might render your configuration files with errors, preventing rules from working, or worse a whole service not working as intended.
Thanks for the help btw
You're welcome. I suggest you think through your plans properly before starting out the coding process. If you are looking for certain methods there is the SME Server Developers Guide, which you already found, the perldoc command for the different esmith::DB classes as well as the already written code in other contribs, or perhaps better the SME Server's own code to learn and borrow from.
As a last peace of advice: Not that we do not want to support you in the forums, but for development we have a special mailinglist:
http://lists.contribs.org/mailman/listinfo/devinfo . Perhaps it is easier to subscribe to that list and ask your questions there.
10 Replies
3594 Views