This electronic book, the WACS Administration Guide, describes the administrative tools used to manage, catalogue and update collections of digital media (images, videos, etc) maintained within a WACS web site. It provides both a tutorial and a reference document for the various administration applications within the WACS system. The intended audience is WACS web site managers and support staff tasked with maintaining a collection within a WACS system. Some familiarity with WACS at a user level would also be a distinct advantage, and we would strongly recommend working through the companion user guide first - who knows it might give you some ideas about neat extra features you can add to your own site. All documentation for WACS is available both within the distribution and from the WACS Web Site at Sourceforge.net.

It is important to stress that ALL of the collection management tools are implemented in Perl and the PHP interface is an optional addition to, not an alternative to, the core Wacs system which is perl based. The php implementation of the WACS system API has always been targeted to php5 and requires a number of additional modules for tasks like database access. The installation guide covers these topics for those people working on platforms and distributions that are not available pre-package from the WACS download area on sourceforge.net.

As the WACS software package is Open Source, we're always looking for contributions; if you create a site design (or prototype for one) which you don't end up using, maybe you would consider donating it to the repository of sample WACS Skins. We can always substitute our own artwork into already written web application code.

For copyright/licensing reasons, the example images feature sets from photoshoots by the main developer of WACS (Beaky) and a friend of his. These sets are now available for viewing and download on our demonstration site PinkMetallic.com which went live in January 2010. Initially this site will be free to use, but we may introduce a charge at a later date to help us fund the expansion of the content or if changes in regulation require us to use a small financial payment to verify age.

Before you set about changing your role within WACS, you need to first determine how the particular WACS installation you are using handles authentication. There are two options available - host based authentication or database authentication. Host based authentication is where access to the WACS system is controlled by the webserver's own operating system user accounts system. This is where all users log into wacs using the same normal username and password which they use to log into the webserver for other purposes. This is most likely to be used on private servers and on free tube style sites where only people performing collection maintenance are even required to log in. Database authentication is where user accounts for WACS are stored within the database itself. This method is most likely to be used on subscription based sites where people have to pay for access. The setting of the authentication mode is determined by the authmode variable within the security section of the main WACS configuration file wacs.cfg. For a new installation from packages, this will normally default to host based authentication unless the WebHost configuration is choosen.

The nature of the way WACS handles leases and permanent rights is not affected by the authentication method used - once the account is authenticated, the rules set in the lease or permanant access control list is what governs WACS' behaviour.

	Note
	Permanent rights based on a fixed IP address and account combination will not be automatically updated. If you are using permanent leases, you will need to seperately modify the role entry in the section for that IP address to read either admin or power to enable the admin modes

What to do - Database Authentication

Generally things are quite a lot simpler when using database authentication as the WACS user database is usually preloaded with three default accounts :- root, support and guest . Of these root has full admin rights, support has power user rights and guest has normal user access. The default passwords for these accounts are as follows:

Username	Password	Role
root	Svjck981	admin
support	uKiFt126	power
guest	freebie	viewer

	Tip
	These default passwords might change in future, for the current value (ie if these don't work), you can check the file user.xml in the populate directory of the wacs distribution.

If you logged in at the start of this WACS session, you will be using the lease-based security mechanism - this is the easiest type in which to change your account status to gain access to the administration tools. To make the change, you first need to log out of WACS; this can be done very simply by clicking on the logout link at the top right hand corner of the WACS main menu (aka front page). Once you've logged out you need to edit the main WACS configuration file, usually called /etc/wacs.d/wacs.cfg and find adminusers. This can be done with any text editor capable of working with XML or plain text files which you are familiar with. Once you've found the adminusers entry, simply add your account name to the list, separated from the other entries by a comma if necessary.

In this example we'll add johnd to an existing admin users list that includes the wacs account itself, and two other users called Karl D and Julie K (account names karld and juliek respectively).

Before:

  <adminusers>wacs,karld,juliek</adminusers>

After:

  <adminusers>wacs,karld,juliek,johnd</adminusers>

	Note
	In keeping with normal Unix practices we do not allow spaces in user names. Our accounts are of course often the same as the Unix account names; definitely so if we're using Host Authentication but still a good idea even if we're not.

Once the account name has been added to this file and the modified file saved, we simply log in again using the normal WACS login page and our user status will have changed. We can then proceed the next major section (the section called “Everything Looks Different”) on how to make use of our new found additional priviledges.

The actual current level of access is determined by the role field within the active leases file. If you want to grant extra priviledge for only the duration of the current lease, you can do this by directly editing the lease file. The default location of this file is /var/run/wacs/leases.acl and if you call this file up in an editor you just need to find the entry with the correct IP address and username and change the role in that entry from viewer to admin.

Here we have to deal with a slightly different concept. If you make the changes detailed above, whenever and from whereever you log in, your account will take on the elevated status it has been assigned. This is because whenever you login your right to elevated status is checked for in the configuration file and your access right record for that IP address in the leases file set accordingly. A permanent access right is based upon a particular permanent IP address and doesn't go through this assignment process. It is therefore completely possible for a given person's PC (so long as it has a fixed IP address) to be given administrator access but for that person not to have any elevated access when using their account from other system. In some cases, this may be what you want, although it would preclude that person working from home, etc. Similarly you can also use this mechanism to offer automatic administrator priviledge to anyone logged in on the local system itself.

The permanent access rights are controlled by a file called wacs.acl which lives in the same directory as the main Wacs configuration file. This will typically be /etc/wacs.d , but might be elsewhere especially if multiple Wacs servers are running on the same web server. If the Wacs install has been done using the packaged versions (.rpm or .deb), a sample entry showing how to do this will be included but commented out in the installed default wacs.acl file. Once uncommented, this looks like this:

<?xml version='1.0' standalone='yes'?>
<accesslist>
 <ipv4-127.0.0.1>
   <user>wacs</user>
   <type>permanent</type>
   <date></date>
   <role>admin</role>
   <prefexcl>D,B,C,F</prefexcl>
   <usedirect>yes</usedirect>
 </ipv4-127.0.0.1>
</accesslist>

Each section of the file is enclosed by a <ipv4-host_IP> and the entries within apply to that host address only. There is one magic entry, <ipv4-all> which can be added to disable the access control system entirely. Looking through the fields in each entry, the first one, user, gives the user name to attribute accesses from this host to. The second attribute, type, is either permanent or lease. If it is permanent, access will always be granted as the specified user to this IP address. If it is lease, access will be granted until the time/date given in this field (in unix seconds since epoch date format). The role field defines what level of access this user should be given to make modifications to the database.

In many cases where the site owner is not worried about security or who can access the Wacs system (providing they have access to the machine), uncommenting the entry for ipv4-127.0.0.1 in the wacs.cfg is probably the easiest thing to do. Generally this lets the console user manage the system fully and requires everyone connecting in over the network to have to log in. However this mechanism is a little simple-minded and can be circumvented by someone with some knowledge and a genuine login account on the server.

You can also use the same mechanism to grant permanent access to any other IP address on the internet, including obviously certain machines on your local network. Shown below is a sample file that grants such access to two machines on the local network - in this example johnd is an administrator and billw is either telephone support or a salesman - he's only a power user!

<?xml version='1.0' standalone='yes'?>
<accesslist>
 <ipv4-192.168.1.15>
   <user>johnd</user>
   <type>permanent</type>
   <date></date>
   <role>admin</role>
   <prefexcl>C,F</prefexcl>
   <usedirect>yes</usedirect>
 </ipv4-192.168.1.15>

 <ipv4-192.168.1.17>
   <user>billw</user>
   <type>permanent</type>
   <date></date>
   <role>power</role>
   <prefexcl>D,B,C,F</prefexcl>
   <usedirect>no</usedirect>
 </ipv4-192.168.1.17>
</accesslist>

	Warning
	Of course if you're using the IP addresses for this purpose you do need to make sure that they are statically allocated and that each person's PC is always assigned the same address. You wouldn't want billw getting administrator access just because he was the first person to switch on his PC one morning, now would you?

One of the most simplistic layouts is to simply divide up the models by one key attribute and then by name, as shown in the diagram above. In this case we've choosen to use hair colour, which will probably work reasonably well for most sites featuring Caucasian (white) models and expecting no more than 30 to 50 models in all. In this case the sarea will be things like: blonde, brunette, redhead, and dark hair. You'll probably find that the section for blondes is significantly bigger than that for redheads, but that shouldn't be a surprise. Of course, if you're running a site with a particular niche like Oriental or Goth models, you may well find that you need to use a different criteria for the sub-division.

Despite being simple, we'd not particularly recommend laying it out in this way - putting all the sets by a model in a directory named for her isn't really the best approach as you can always find those sets simply by looking at her model page. You also need to consider what you'll do if there are multiple models with the same name - We've seen some of the big sites with over a hundred models called either Maria or Jana!

When Wacs was originally developed, it was being used to collect sets by selected models from a number of different subscription web sites and it seemed logical to organise the sets based upon the site from which they had been collected. This diagram represents that layout and this type of layout is still very much supported by setting the layout->vendormode attribute in the configuration file to Y and the layout->style attribute to modelattr. Additionally if using this layout, you may wish to use the modified menu configurations described in the AppNotes area.

The cornerstone of this layout structure is that the source site is the highest level grouping (the sarea). Underneath that we have combined the model's hair colour and breast size description into a single combined description. Generally this serves to divide each site's directory at this level into between 10 and 20 sub-directories, and even with a very large site (> 2000 models, 30,000 sets) this seems to remain reasonably manageable. Within each of these directories is a separate sub-directory for each model, and therein her set.

There are of course exceptions to this and over to the right hand side of the diagram, marked out by a green box, we have the sapphic erotica area. Since (almost) all their sets feature two or more models, focusing the organisation of material sourced from there on individual models makes much less sense, so in this case we use a completely different layout where we're grouping by number of girls in the set and location in which it happens. While the default system won't guess that much, it's absolutely OK to use a completely different organisation structure as illustrated and it'll all work fine. Notice also that whereas mostly in vendormode we're using two parts to scategory, namely the model attributes bit and then her name (as in blondes_smallbreasts/Chelsea), for the sapphic erotica section we're only using a single level sub-directory structure. So long as all of the image folders are at the same level within the sub-directory tree, this works absolutely fine.

In summary, vendormode is a good site architecture, particularly for collectors who are accumulating works featuring their favourite models in a private WACS server. It is not as appropriate for a commercial site or one that is based upon a less collection orientated activity, and that is where our third standard site design comes in....

The final layout that is supported in the defaults mechanisms within Wacs is a gallery layout of the type favoured by a significant number of the existing adult web sites on the internet. That is not to say that these are the only options, they are merely those which are supported by the defaults mechanism within the existing Wacs code. You can easily devise your own layout in most cases Wacs will support it providing a few basic premises are adhered to.

In the gallery layout, the toplevel organisation is by the type of content featured within the set; this means the toplevel will typically be things like: toys, lesbian, straight, solo, and masturbation. Essentially the top level sarea is the same as the standard set type category. The next level down simply consists of the word gallery followed by a three digit number within each top level category. As each new set is imported into the Wacs system, it is automatically placed in the gallery with the next available free slot within the appropriate top level category. This method gives the opportunity to view a number of similar sets from a range of models within the same container which seems to be a popular and accessible way of browsing collections. Of course all the sets can have links to the model pages of the models featured.

Of course all the latest sets tend to be in the highest number gallery for each category, and a number of the Wacs tools include configuration options to show the latest first and in some cases limit the number of gallerys shown for speed of display.

Wacs provides a lot of flexibility in it's support for site layouts but unless you have a particular need for a custom style of your own, you are probably best off using one of the standard styles outlined above. Consider carefully what you choose as it is definitely significant labour to change the layout at a later date, although tools that can do it are provided. Generally it is worth choosing either the vendor mode or gallery mode; the simplistic mode will only really work for sites where you are hosting solely your own content or have a very specific scope of interest which will result in only a very small number of models.

Please see the configuration manual chapter on layout to see how to make the selection of default values match your choosen layout. The configuration variables you will need to tune are vendormode and style. The next chapter will discuss how the actual container directories are named.

Conventionally in Wacs we give sets pretty long names - generally all contemporary operating systems cope just fine with that idea - and those long names impart as much information about the set as we can possibly squeeze into them. What happens is that you describe the set, and that description is used for the directory name in which that set is placed. This is part of our policy to leave your content freely accessible and as usable as possible from outside Wacs as well as within; we DO NOT swallow your content. Our naming conventions are totally designed to make other methods of finding files benefit from the effort put into making them work under Wacs.

The standard Wacs format for set naming uses some basic conventions for how the names are assembled. There are considered to be three basic parts to a set name - these are:

Each of these items are divided from the previous one by way of an underscore (_) character. Wacs will always replace the underscore with either a new line or a space; whatever best suits the way in which the set details are being displayed. Additionally Wacs uses a technique called Camel Text (so called because it has lots of humps in it) to further divide up the description to make it more readable. This is basically done by starting each distinct word with an upper case letter and having the rest of the word in lower case.

Using these basic styles and constructs, we build up a name for the set that is simultaneously suitable for use as a directory name and as a description of it with a fair amount of detail. Putting it all together, we end up with a typical simple directory name looking something like:

Once we've selected to name a set in this way, a keyword matching process will be applied to that name. Looking at this particular example set name, we will hopefully find that we do know the model Sarah and so will be able import a number of details directly from her model record. Moving on the NoPanties phrase adds a set marking attribute called nopanties. The Garden keyword will cause two mark-ups to happen - a set marking attribute of outdoors will be added, as will a location attribute of Garden. The Dress keyword will cause the general clothing type to be marked as Smart as generally such dresses are. Of course if the keyword guesser gets it wrong, you can always correct it manually, but through slightly careful choice of the words we use, we've already determined no less than four things about the set.

Wacs will also add in the details about Sarah herself extracted from her model record, additional information about her such as whether she shaves her pubic hair, whether she has tattoos or piercings and whether she has unusual attributes like exceptionally small breasts or short hair will also be copied across to the set. Of course these change over time, and it is possible to correct these settings manually - we will discuss this later in Chapter 9, Wacs Set Manager. The net effect of all this is that we can now search for things like "Show me all the sets with girls with shaven pubic hair and no piercings in smart clothing but no panties in the garden."

Hopefully you will appreciate how much information we've managed to extract from relatively little work on your part by way of carefully selecting the words you choose to use to describe the set. It will obviously take a little bit of time to get familiar with how the keywording system works and what the keywords are. Over the next chapter or so, we'll hope to provide an introduction to the most common keywords and the effects that they have. We'll also take a look at the keyword maintenance system itself and in particular how you can add any additional keywords that you like to use into the list of what the Wacs system makes use of.

You're probably thinking that surely it can't be that easy and that a keyword scoring system like this is bound to make mistakes. Yes, it is and it does BUT in our experience such mistakes happen rather less than 5% of the time, which means that only maybe one in twenty sets needs manual attention to correct erroneous attributes applied to the set. We often add more, which is reasonably easy to do, but the fundamental point is that the keywording system works quickly and efficiently to build up a surprisingly comprehensive amount of structured information about the set. The level of accuracy is enhanced by a system of keyword scoring.

Each keyword the Wacs system knows about has a record in the keywords database, and for each of the possible types of attribute that the Wacs system might derive from it is both a value and a score. Thus if Wacs sees the keyword Garden, it notes a 7/10 score for a location of Garden, and a 5/10 score for a set attribute of outdoors. This means that it's really pretty sure the set is located in a garden, and thinks it's odds-on that it's an outdoor set. There's actually also an explicit exclusion of the phrase IndoorGarden, so that the normal attributes added to anything called Garden aren't added in the case of IndoorGarden.

At the other end of the spectrum, there are some words that have a very light "it just might be" level of binding. An example of this is the word Denim which gives a score of only 2/10 for it's assertion that this is a casual clothing style. Similarly the word armchair gives a very uncertain binding of just 1/10 that it might be in a lounge - any other location keyword like bed, dining table or kitchen will immediately override that lounge idea. The Wacs developers have actually done quite a lot of work on making the words bind with sensible strengths for the many sets in our testing database and generally the guesses are a lot more accurate than you might expect.

An example from Wacs Keyword Manager

If you take a carefull look at the above example which is a screenshot taken from the the section called “Keyword Manager”, you will see at the top of the list that the keyword Country, so long as it is not merely part of CountryView, will cause a score of 4/10 for a location of Country and a score of 5/10 for the attributes of country and outdoors. This is so that the phrase CountryGarden will not overrule the location of Garden but will also add the country attribute mark. The two resulting attributes, country and outdoors are represented here by their respective icons. You can check the exact attribute words used by editing the entry, but that is a topic for the section called “Keyword Manager” rather than what we have here. The main thing to consider at this point is to have some understanding of how the mechanism works and to be aware of the wacskeywordmgr and how to use it to browse the preloaded keywords and what they mean.

However before we leave this introductory chapter on keyword scoring we'll just take a quick look at some of the most common keywords that we are likely to want to use frequently.

While we've just taken a look at the mechanism by which the keywords work and how we can examine the definitions and so on, that probably doesn't make you feel ready to use them right away. So we'll take a quick look at some of the most common keywords, what they mean and how they are represented so you can start making use of them as we progress to set unpacking and placement techniques.

Let's look initially at some of the clothing keywords that result in both clothing style and set attribute markups. Note in particular that we've decided that we want to sub-divide uniforms into multiple categories such as medical, hospitality, military and labourer rather than have a generic uniform clothing type. We could easily add a low-priority binding of uniforms to be of a simple clothing type of Uniform if all other uniform keywords fail to match. In fact, that sounds like a perfect task to do with the keyword manager when we're reviewing that in a later chapter (the section called “Keyword Manager”).

Table 4.1. Clothing Related Keywords

Keyword	Clothing Type	Attribute Name	Attribute Icon
NoPanties		nopanties
SeeThru		seethru
Uniform		uniform
Schoolgirl	Schoolwear	schoolgirl
Cheerleader	Schoolwear	cheerleader

Even marking up using just these five icons will actually make quite a difference to what you can and can't search for within your Wacs managed collection. Of course these icons are only a very small proportion of the story; there are at least two other major categories which only affect the location and action section of our naming convention. These are those that show an action and those that show a location.

Starting with an action, we have a number of keywords that help define the type of the set: the keyword FUCK indicates a straight sex set, as does the keyword Blowjob, while other words like Dildo typically indicate a toys set. Do note however that once again the scoring system comes into play and a set that is marked as lesbian and includes the word dildo will remain marked as a lesbian set because of the higher score although it'll gain a the dildo attribute as well. Other commonly used keywords for the actions include Anal for anal sex, Fisting and Piss for those respective actions.

There are additional attributes for that third part of the name which describe locations rather than actions, these include Garden which implies outdoors; Beach, River, Lake and Sea which imply outdoors and country.

Hopefully these examples give you somewhere to start when naming your set. Do remember that use of none of this is mandatory - calling something simply "set23" or "Sarah_Set23" will work just fine. However we feel it would be a shame not to use this feature to help you get started with the mark-up process. Do also remember that you can easily add more attributes not covered by the keyword system using the rating facility aka Chapter 9, Wacs Set Manager. We will return to this topic in later chapters.

	Note
	With WACS 0.9.x it is possible to define your own new attributes with your own icons and meanings. These features will be made accessible via the web interface in a future release - at the moment they have to be defined in the database itself using SQL. More details on how to do this can be found in Chapter 18, Customisation.

The concept of rank is that each and every set is now considered to fall into one of three categories (plus undetermined - ie not set yet). These are:

	Note
	If a set has no value for srank it will be treated as if it were a Primary set.

So as you can see from this it now becomes fairly simple to hide sets that aren't needed from searches and new release listings while their purpose for being there is reasonably clear. However to make this mechanism useful, there is a further feature that is needed - the ability to tell which set is related in this way.

With the Rank mechanism above describing each sets role within the larger picture, we need additional information in order to make the necessary connections between related sets. To allow this to happen a number of fields now exist within the database (used from Wacs 0.9.0 onwards) to explain exactly what those relationships are.

The first of these fields is called sduplicates and it contains a set number allowing the set ranked as the primary to refer to it's secondary. The secondary set typically refers back to the primary in the same way, but can refer onwards to another alternative secondary set before that refers back to the primary. A number of special calls are available to Wacs Programmers making it easy to follow these links.

The next pair of fields are concerned with continuation sets. For these records it is quite common to have as many as four or five shorter video clips tied together and so we provide links to both the next set (field: snext) and the previous set (field: sprev).

The final connection mechanism is for alternative media - that is when we have a photo set and a video clip both sharing common attributes. This is probably the most common scenario of all in the adult industry. The field for this is known as saltmedia. Normally these just link between the photo set and the video clip with each linking to the other, but you can make a chain if you wish to including details of a DVD release or audio file as well.

	Note
	You won't need to worry about these database fields themselves other than to know they exist and why they're there as the collection maintenance tools all know about them in Wacs 0.9.0 and you will be prompted with a pull-down menu of suitable options when you select a Rank that needs them.

The majority of Wacs applications are now aware of these fields and values and make use of them appropriately. No doubt we'll improve things over time but the basic building blocks are there and you can start using them.

The first step of course is to start up the GIMP, either from the command line or via the Applications->Graphics menu, and then open the image we wish to work on. The screenshot above illustrates how the GIMP should look once you've openned the image; in this case we're using a shot of Roxanne.

Since the image is currently 1125 x 1500 pixels (that information is given in the title bar BTW), we're first going to reduce the size of it so that we have a reasonable chance of getting more than just her eyes and nose in the picture. To do this we call up the scale image tool from the Image menu as shown above.

The first headshot icon we're going to produce is the larger of the two, the one at 260 x 340 pixels. We will then produce the second smaller one by scaling down and/or cropping further that image. Anyway, the key point to bear in mind is that we're aiming for a portrait shaped image of 260 pixels across and 340 pixels tall.

Once you've called up the image scaling tool, the following dialog box opens up and you get the chance to reduce the size somewhat. By exactly how much depends on both the image your working with and the size and style you want for your site. Some sites may prefer a full torso shot either clothed or nude, while others may prefer a simpler head and shoulders style.

You'll notice that the two image size figures (here 1125 and 1500) are linked together with a chain icon. This means that they will change in union in order to preserve the current shape (aspect ratio) of the image. This is perfect for what we want here, so if we just overtype the 1500 with half that, ie 750 we will shrink the image to half it's current size. At that point we should in a position where a 260 by 340 selection from it will make a reasonable headshot icon.

Tip

If the photo we are working with is already more of a headshot than a full torso shot as this one is, we might choose to use a value of 500 to replace the 1500 instead of the 750. This will mean that our 260 x 340 selection from it will comprise a larger proportion of the original image. Bottom line, you may have to try several different values until you find a value that you are comfortable with.

Once you've clicked on the Scale button, you will probably find that the image is now smaller than the window - going to View -> Zoom and choosing 1:1 (100%) should make it fill the window again. Simply pressing the 1 key should also have the same effect. The next step is to put Gimp into rectangular selection mode and select the appropriate area of the image.

In the top left corner of the screenshot, we've highlighted where you need to click on the rectangular area selection tool. Once you've done this you left-click-and-hold on the top corner of where you want the icon to start and then stretch it to the bottom right hand corner. If you watch the boxes on the lower left side that are also highlighted, these will show you the size of the current selection. The pair of numbers above are the current position and are not relevant to this procedure. Once you have these numbers showing as x = 260 and y = 340 , you can let go of the left mouse button. A further left-click-and-hold within the selected area will allow you to move it around until the best cropping position has been found.

	Tip
	You don't have to struggle with the mouse to get the precise sizing right - you can just click in each of the two dimension boxes in turn, type in the desired value and then press return. This will make the wireframe crop box into the desired size and you can then just use the left-click-and-hold to allow you to maneuver it over the image until it's giving you the right sort of headshot.

Once you're completely happy with the headshot cropping and the size of the area you're working on, you then need to actually perform the cropping itself. You do this with the Crop to Selection option on the Image Menu.

Once this is done, we should be left with our final version of our large size headshot. The file step is then to go to the File Menu, choose Save As... and give it a suitable name - in this case we've called it Roxanne-big.jpg. The Save As... will pop up a dialog box asking for the new name - you should make sure it includes the filename extension as this determines the type of file created. It defaults to the same file type as the image it was derived from.

Once you've given it a name and clicked on the Save button, you will normally get a second dialog box related to options for the particular type of file you're trying to save. The only one we usually change is the quality, which we would recommend setting to 85% percent for JPEG images. For PNG images, we usually recommend compression level 6. Of course it doesn't really matter what you use, but you want to strike a balance between quality and the size of the file - these headshots will be downloaded a lot as people browse your Wacs site.

The next step in the process is to produce the small icon at 120 by 156 pixels. The first step in this process is to reduce the icon further in one of the dimensions by using the Scale Image option from the Image menu. The simplest way to do this is to type one of the desired sizes into the image scaling dialog box as shown above. As you can see, our 260 x 340 icon reduces to 120 x 157 when you specify an x dimension of 120. That's basically within a rounding error of the 120 x 156 value we were looking for - ie just one pixel off. While we want to be careful about distorting the image, changing 157 to 156 is a 0.75% error which is pretty negligable - it's not about to change the whole shape of her face or anything like that.

To make this change from 157 to 156 without affecting the 120 value (which is correct), you need to unlink the chain symbol between the two numbers. Then you simply overtype the 7 with a 6 and press the Scale button on the dialog box. The image is now scaled suitably and you can proceed to do a Save As... to save it, calling it something like Roxanne-small.jpg. You can now quit the gimp - we're basically done with it.

The absolute final step is to copy the finished icons into the right place to make use of them. This is fairly dependant on how the relevant Wacs site has been configured, and as mentioned earlier, the definitive answer is the values of modicons and modbigicons in the fslos section of the Wacs configuration file, wacs.cfg for the site in question. The convention is to have the files named the same but in different directories, so in the default locations for the packaged versions of Wacs, this would be /usr/share/wacs/html/icons/Roxanne-1.jpg for the smaller icon and /usr/share/wacs/html/bigicons/Roxanne-1.jpg for the larger icon.

Table 5.1. Final Example Headshot Icons

Big (260x340) Icon	Small (120x156) Icon

Let's start with the basic model attributes - the colour and length of her hair, the size of her breasts and the way she keeps her pubic hair. These are to be found in a group in the upper left portion of the main model manager screen.

Hopefully the choices for hair colour and length are reasonably self- explanatory - the key thing to remember here is Usual. If she usually has long hair, and then suddenly appears on a couple of sets with a short bob cut, the length should remain long (although you might wish to manually flag those sets with the shorthair attribute - how to do this will be covered in Chapter 9, Wacs Set Manager). The pubic hair value should only be shaven if her pussy is completely shaven; a Brazilian style shave leaves a small tuft of pubic hair above her clit but nothing on either side. Note that this is such a decider for some people that we actually mark up sets whereever we can with an attribute describing the pubic hair style.

The breast size value is much more subjective but our take on it is based upon the probably apocryphal description of how to decide when a young woman needs a bra - simply put “Will a pencil put underneath her breast stay there?”. The table below gives our rules of thumb for these values:

Table 6.1. Breast Size: Our Take

Value	Icon	Description
Tiny		Rolling the pencil up her chest, the first bump you notice is her nipple... if at all. This should also be marked with the tinytit attribute.
Small		Rolling the pencil up her chest, it stops when it reaches the underside of her breast but probably wouldn't stay there.
Normal		The pencil will stay there, no problem.
Large		Hey Lady, Where's My Pencil?

One final aspect we'd just comment on in this area is that of race - most of these should hopefully be self explanatory except that we have divided up Asian into two using the traditional British descriptions - the word Asian is used for complexions native to the Indian sub-continent while Oriental is used for those from South-East Asia and the Chinese sub-continent. Hopefully this distinction is reasonably obvious.

The next section we're going to look at is the fields for entering the names of the previously prepared headshot icons. As discussed earlier the files need to be copied into the directories specified for modicons and modbigicons in the wacs.cfg file. You do need to include the file type extension on the end of these filenames. It's perfectly OK to place icons into sub-directories of the model icon directories, and to give the relative pathname including directory path components here.

Finally down the bottom of the model manager main screen, we have the mark-up attributes. These are attributes that apply directly to the model herself and cover such things as pubic hair style, and various types of body modification: tattoos, piercing, breast augmentation, etc. Normally what you specify here will be automatically copied into the attribute marking of all sets she's involved in. That's not to say it isn't possible to remove specific details on a per set basis - it is. Thus if a model gets a tattoo or boobjob later in her modelling career, these can be added to just those later sets. Generally it's a value call as to what is the most common state across the collection you have of her as a whole.

For Roxanne we set just two model attributes - shaven because she is in our sets and piercedtit because she has a stud through her left breast's nipple. Once we've selected these, we can click on the Summarise Changes button and we'll move on to the next model manager screen.

At this point, since we're creating a new model record, we go through the process of inserting a new record -- that is the database terminology for it. The first screen we see after the main model data entry screen, is the one shown below which summarises what the new model record will look like and shows you the headshot that it's going to use so you can confirm it's all as you expect. Notice that we do actually show you the SQL command we're using at this point. Should anything go wrong and you're seeking help - please cut and paste this SQL statement into the request for help - it will make it much easier for us, or whoever you get your support from, to work on solving the problem.

Do take a careful look over the details given here just to make sure that you haven't made any obvious mistakes, like misspellings or ticking attributes that just don't apply. Once you're happy, click on the Commit Changes button and you should see this:

As you can see this confirms that the main model record has been created and immediately prompts you to enter an initial identity. You don't have to do this, you can click on the link over the “created as model no” link or on the Quit - Return To WACS Main Menu link at the bottom. The pull down menu allows you to select from the predefined sites. You can add additional sites using the Wacs Vendor Manager (described here: the section called “Vendor Manager”).

Here is a purely fictious example of an IDmap for a fictious model called Roxanne A, but hopefully it'll illustrate how we add a new IDmap. We actually only need to add two items over and above the defaults - the first is the Site where we've selected Karup's PC from the pull down list; the second is that her key here is roxannea (which doesn't exist BTW). If we'd been working on Sabrina, we'd have choosen Sapphic Erotica, entered a key value of 422 and added a space and a capital M after her name as she is known there as Sabrina M instead of just Sabrina. Once we've got the necessary information entered into this form, we click on the Add This IDMap button and the IDMap should be added to.

This page basically confirms that our new initial IDmap has been added, offers us a link to edit it further and offers us a number of alternative “Where Next?” options. We will look at the ways of editing an IDmap using wacsidmgr in a later chapter.

At this point we've basically finished the process of adding a new model to the WACS system - granted it's a little involved, but it is still fairly quick and easy. In addition to adding new model records with the Wacs Model Manager, it is also possible to add new model records using the command-line based addmodel facility, although mostly these days that would be used when creating scripts to import models automatically from other systems. More information can on addmodel can be found in Chapter 17, Command Line Tools.

We have now covered how you create a new model using wacsmodelmgr but that only covers a fraction of what it's capable of. It can also update existing model records, import model records from XML files and add new IDmaps (records of a model's identities on various sites). We'll look at just the updating of existing model records now and cover the rest of these topics in a later chapter (Chapter 15, More About Model Manager).

We said earlier that each administrator, ie you, can only unpack one set at a time. Obviously there are times when you forget this or some kind of failure occurs and things are left in a messed up state. If this happens, you can expect the unpack manager to present you with a screen something like this:

Here we have a screen shot of the set manager working on our newly added Sabrina set. There are seven basic parts to the set manager display: the masthead (summary of the set details), Update Control, Set Type, Ratings, Set Attributes, Photographer/Clothing and finally Location. The masthead is common, but the second of these is a bit more complex.

As we saw in the previous chapter, the placement manager runs a command called updateinfo which does all of the keyword searches and importation of model attributes to kickstart the attribute marking process. Each time it visits a directory, it will attempt to update the meta data if it can - mostly this is a good thing because if the set name includes a keyword that was not recognised first time (for instance if it's been added since the last run), the new attribute will be added to the set. However, there are occasions when that system doesn't work as desired and it's necessary to be able to override the automatic guessing process. This is done through the Update Control flag - there are three commonly used modes - Fully Automatic where the attributes are changed automatically to whatever the new keyword scan produces; Append New, Remove Nothing where newly added keywords will get their attributes added but none of the previous entries will be removed, and Location Only which only allows changes to the media file location details. Of these Fully Automatic is the default, Append New, Remove Nothing is selected as soon as you add additional attribute information to a set using the set manager; and Location Only will not update any of the attributes. You would typically use Location Only or No Changes - Manual where something was giving a false positive on a keyword search. An example of this was a model called River who's name triggered the country and outdoors keywords. These flags of course make sense normally, just not in her case.

As we continue down, the next attribute section is the options for the various types of set available - hopefully this is reasonably straight forward and we've discussed it several times before. The next one down is for the ratings - again we've looked at these values before - see the user guide and schema reference section of the programmers guide for more details.

Now we reach the big section - all the possible mark-up attributes for sets. Hopefully all of these are reasonably self-exaplanatory and again we have discussed these before, particularly in the user guide. The next section has the Photographer and the Attire pull-down menus - the photographer list includes all currently defined photographers. Photographers get incorporated into the Wacs system in two ways; either by being imported from the supplied initialisation XML file when you create the database tables (see the installation manual for more info, and the entry here photographers.xml) or by being created using the photographer manager which we will be looking at in a later chapter (the section called “Photographer Manager” in Chapter 11, Other Web Based Tools). The attire settings are a little bit more complex as it basically offers you a choice of any the existing options that have already been used. There is of course a slight problem here in that options won't be listed here until they've been used at least once, BUT we've done our best to ensure that there is at least one keyword that will match each of our standard wordings for the attire value. If there are new words you want to use you can either:

An example on how to do this latter option is given in the section called “Adding A New Type Of Attire” in Chapter 19, Simple Tasks In SQL. The final values relate to the location and detailed location fields, which again are usually derived from the keywords database. As before you can define new locations by either editing the keywords to add a new one, or by manually adding one entry to the sets database using SQL whereafter it will appear in the pull down menu.

We're going to look at using the set manager to make an update or two to our newly added set of Sabrina on the white sofa. We're going to rate it and modify the attributes to reflect the fact that Sabrina has a Brazilian shaved pussy rather than fully shaven in this set. To do this we select the three ratings - for overall we've choosen 3 - Good , for variety 2 - Cute Twist as there's a couple of neat moments when she's sitting up on the back of the sofa and 3 - Good for technical quality as it's taken in a well equiped studio with a range of camera angles.

Having selected our ratings choices from the pull down menus, unchecked the tick box next to shaven and ticked the box next to brazilian, we're ready to make the change so we click on Summarise Changes.

Here we see the summary of the changes we're proposing to make, along with an additional indication that because we're made a manual change which would not be picked up by an automatic rebuild, the set's update method has been altered from Fully Automatic to Append New, Remove Nothing. If we then click on Commit Changes we come to the final screen where it confirms the updates made.

As you can see here, it has now updated the database entry for this set with these changes. It then offers us a selection of links to things with might wish to do next, including updating the information for this set which takes us to the Wacs Information Manager and the topic of the next chapter...

	Note
	There are other links here allowing you to view the set again, add another model to it and to add it to a connection. We'll cover these topics in later chapters.

Here we're just going to walk through a simple example of using the wacsinfomgr to modify a few details of our Sabrina set on the white sofa. We're going to do three things: set the production date to 12-Aug-2006, set the release date to 07-Dec-2009 and add an official icon at solo/gallery010/Sabrina_PinkJumperWhiteSofa.jpg. The first step is to enter these values into the screen as shown above and then click on the Summarise Changes button.

At this point we get the usual confirmation summary letting us know what wacsinfomgr is about to change. As usual, check it over and when happy click on Commit Changes button. As before to correct a value use you web browser's back key, but do make sure you use the Summarise Changes button to return to the confirmation screen with the revised values.

Here we see the confirmation of the changes made and the confirmation that they have been saved to the database. If set moves were involved here you would see the move process taking place and the generate command being re-run to re-index the new set, generate a new thumbnail and re-scan the titles for newly added keywords. As usual, a range of links to other related options are offered on completion of the update.

	Note
	With release 0.8.6 we believe we've now fixed the outstanding issues with the automatic relocation of icons when their location is changed. If you find a bug in this area, please report it.

The main tool for creating these download records is a web application called wacsdnlreg which was introduced in Wacs 0.9.1 and is available from Maintanence menu of the Main Menu when viewed by an account with administrator rights.

Selecting wacsdnlreg from the Main Menu (admin)

You do need to start this process with a reasonable idea of both the current highest set number you have and the order in which you wish to add the new records. In this example based on our demonstration site www.pinkmetallic.com, we're going to be adding a new photo set by Kaz B in our Rock Star series. The last set added was the SD version of her "Disco Diva" movie which was set number 32. The wacsdnlreg will default to offering you the next available set number, ie 33, but you can override this. You will want to do this if you KNOW that the content you're working on now is not going to be the next set to be released. It is your responsibility to keep the set numbers and the corresponding download records in step and the download records will not serve their correct purpose if they fall out of step.

wacsdnlreg model and site details screen

The wacsdnlreg application will default to showing you the model with the most recently added download record, and in the pull down menu offer you up to 25 other models with recently added records. There is also an option to use the model number specified in the model number entry box to the right if you're adding the first download record for a new model. Make sure you have added an idmap entry for the model on your site first, but this can easily be achieved using the wacsmodelmgr application's ID management mode. (See Chapter 6, wacsmodelmgr - The Wacs Model Manager for more info).

wacsdnlreg default set details

As you'll see from the above, the defaults aren't particularly imaginative but are serviceable. You do need to specify the archive file and ideally the URL as well. Here we're changing three things - we're changing the set name to Kaz B - Hot Rock Chick, we're specifying the download URL and we're giving the name of the zip file. For any wacs site, the download URL will take the form of sitename followed by /cgi-bin/wacs/wacszip/set and then the set number (in this case 33) and the desired extension (in this case .zip. The zip file name is used far more in Wacs 0.9.1 and is better handled and more used that it used to be. It's definitely worth specifying as something sensible

The Completed Set Details

Finally you submit the form and get a result page like this one. The next step is to proceed to the model page and either connect this download record with and existing set, or unpack the media files for this new set. If you want to see a summary of the recently created download records independantly of the models, you can do that using the wacsdnllist webapp which is also linked to from the Maintenance menu of the main menu when logged in as an admin account.

The Confirmation Of The New Download Record

While it may seem odd to have this set of download records for your own content, it has actually proven to be very useful should the need arise to merge the contents of two sites, or should you need to redo the content of a site for things such as customers demanding higher resolution photo sets.

The main changes to allow for content and thumbnail caching involve configuring values for the content cache areas within the WACS configuration file. If these values have non-empty values, they will be checked for the existence of a cache prior to falling back to using the conventional cgi-bin program normally used by WACS.

The login and logout programs will update the .htaccess files in the appropriate toplevel of the content cache tree. There can be up to three areas in here: images, videos and thumbnails depending upon the configuration. The simplest of these is the thumbnails which is automatically used if the server configuration section attribute serverturl is set to a suitable value. If no cached version of the thumbnail is available, the wacsthumb application will create one for the next time. Use of these depends on your application making use of the thumblink WACS API function when you add a thumbnail to your page.

For image sets, the caching process works a little differently - Nothing is automatically cached - you have to manually decide to cache a given set using the the section called “The wacscachectl command” command. This command will create a suitable .zip file for the set on demand.

% wacscachectl --create 123
[...]
%

At the simplest level, it works in much the same way for standard videos except that generally the stored video clip is exactly what we want to present to the user (no need to make a zip file) and so in this case the wacscachectl command will create an appropriate symbolic link to the video file within the stored video tree. The system does however provide for rather more complex features if required, but you do not need to use them if you don't want to.

Note

We've started using the long-present but thus far unused sdownload field in the set record for the name of the download file for the set. The new wacsdnlreg command allows you to specify this when creating the download record, or if the material has been downloaded from another site the name used there will be preserved. The name can be set on older records and changed using the Set Information Manager app (wacsinfomgr).

A recent change to the Wacs Placement Manager (wacsplacemgr ) has added a tick box that invokes wacscachectl with the appropriate options for a video file from the web interface when desired. This will be improved and expanded in future releases, but it has already made the process of creating a download cache much simpler.

A lot of commercial sites out there have got into the habit of dividing up their videos into multiple parts in order to keep the download sizes more manageable. The same occasionally also happens for image sets, particularly amongst those sites who offer particularly high resolution images for download. When a set has been marked up with continuation parts, a whole new aspect of the content cache comes into play.

The WACS content cache system includes the concept of having both raw and cooked versions of the same set available. In a video, the cooked version of the primary set would be a compilation of all the parts, while the raw version would be just that - the unchanged first part of the video itself. In many of the standard WACS apps, this distinction is understood and the link to the video clip is appropriate to the context in which it is presented. The main links go to the cooked compilation of all the parts, while the numbered parts would link to the raw versions of the respective videos.

Where a video is multipart, the wacscachectl command will look in your process area for the necessary combilation video. Your process area is adjacent to the unpack area used in the unpacking and placement of photo set and video files within the download area on your server. The WACS system includes a tool to make the appropriate compilation video called wacsvidcomb for WACS VIDeo COMBiner. We'll discuss this tool a little further in a momnet, but lets just review what we have so far in the caching system.

Let's start with the very simple case of a zip file for a single self-contained photo set:

     set123/
            Sarah_Set01_RedDress.zip

Next let's consider a simple video clip that is fully self contained - here the symbolic link points to the real video file sarah124-solo-1a.wmv within the main /video area but we have used the sdownload field to rename the downloaded file:

     set124/
	    Sarah_Movie01_PinkBikini.wmv
                     -> /video/blondes/Sarah/sarah124-solo-1a.wmv

For our third example, we've got a much more complex scenario where this set number is the first part of a three part movie of which we have made a compilation using the wacsvidcomb application. Here we have both raw and cooked versions:

     set125/
            cooked/
                   SarahAndJane_Movie01_KitchenCuties.wmv
            raw/
                   SarahAndJane_Movie01-part1.wmv
                       -> /video/blondes/Sarah/sarah-jane-gg1-1a.wmv

The wacsvidcomb command retrieves data from the Wacs set record and uses it to create the compilation video by way of the mencoder application that is part of the Linux mplayer video player project. Before the wacsvidcomb program is used, it's a good idea to check that it's mplayer companion can find all the necessary codecs to play the types of video files you plan on converting. They share a common architecture and codec library, so it is a good indication.

At it's simplest level, wacsvidcomb can simply make the compilation using the clips that make up the video sequence as recorded in the database. You must give it the set number of the Primary (first) video in the sequence in order to work. It will produce the resulting compilation, often in better than real time, and place it in your process area within the WACS download directory structure - exactly where a subsequent run of wacscachectl on the same set number would look.

However many of these multipart videos feature 18USC2257 declaration slates on the front of each part of the video that would make an annoying and unnecessary interuption on the compilation video. To this end there is a field within the sets database called sskipfr for skip frame. You can now set this value for video files using the wacsinfomgr as from WACS 0.9.1. Unfortunately it's not quite as simple as you might hope due to the way in which movie files on computers are constructed.

If the movie were uncompressed (which would make it HUGE), then you would specify the number of frames to skip, so if it was a 30 frame per second video, and the slate lasted six seconds, you would put a value of 180 into sskipfr. Simple enough. However it's very rarely that easy and the majority of video compression algorithms start from a special complete frame called an I-frame and then follow it with only the modifications to it. The cut can only be made at one of these I-frames and so the counting is based on the number of I-frames rather than the number of actual frames.

Unfortunately compression systems vary wildly in how frequently they force an I-frame; some every second, some every two seconds and some (like WMV) only on a major scene change. Generally the skip feature of mencoder counts in I-frames and trial and error is the only real way to find the correct value to put into the sskipfr value for any given video clip. Of course you can always do the edit manually with any one of a multitude of video editing applications and place the result into your process directory for wacscachectl to collect when creating the content cache for the set.

Over the time we've been developing Wacs, things have moved on and website owners have become very concerned about the issue of site scrapping - the sucking of all the content off their site by automated downloaders. This not only causes huge additional bandwidth usage and server load, but in some cases costs them real money if they have to pay for the bandwidth used from their servers. As content providers ourselves, we understand their pain, but at the same time having started out as merely avid collectors, we really want to know that we have everything we can get by the models we're interested in.

After initial private experiments with fully automatic downloading, we fairly rapidly progressed to a viewpoint of providing tools that focused only on pre-defined models because the automatic tools were both against the terms and conditions of most sites and because the quantity of material was simply too much to cope with. The public versions of Wacs have always been based on the idea of creating a model definition for those models you like and working from there.

Some recent developments have made it even harder to do automatic downloading with various techniques including extensive use of short-lived cookies and image capture challenges being used. Additionally our usual web browser of choice, firefox has given up on storing it's current cookie collection in a readable text file making it even harder to recover those vital cookies. As a result, starting with Wacs version 0.8.4, we've started a new policy of using web pages with links on as a way of guiding you through the download process. These give you links to what needs downloading next but including the human element to ensure the challenges and other tricks are seen and answered. The older command line based tools are still there and will remain usable for those sites that do not impose additional restrictions beyond username and password requests.

The chkmodel takes a single argument, a model number and proceeds to look at all the IDmaps for that model - for each IDmap, it checks if it knows a username and password for the relevant site and if it does, downloaded the relevant model page from the site. It then checks through that model page for the image set and video clip links, and adds any new ones it finds to the collection of download records for that model. Depending upon what it finds, it will update the models IDmap to show when it was last checked and when it last found a new set for that model. This way those models with an actively growing portfolio are checked more regularly than those who are no longer working and producing new sets.

The chkmodel is also capable of working on a saved web page in an off-line mode for those web sites whose pages are marked as unusable (ie the vmpaguse field in the vendor database entry for that site is set to N for no). Here it will look through the model index page seeking links to set pages and recording the details of what it finds that it did not already know about - in most cases this will probably be an incomplete (download status X) download record. The model's record for that site will be updated to show that it was last checked on the day on which the model index page it processed was saved to disc. The additional details needed can be added using the wacsdnlframe web app at a later time (see wacsdnlframe for more information).

	Note
	The enhancements to chkmodel to allow it to use saved files well were added at Wacs release 0.8.4; additional work to make the naming of saved files easier is expected to be added at a later release.

To save a page for chkmodel to read, it needs to go in a very specific directory - the modelpage-cache directory of the site directory in the download area. In a default package installation, and for a site called wacsdemo, this would be: /var/spool/wacs/download/wacsdemo/modelpage-cache/. The file then needs to be called a very specific name - the first part is the site code (for wacsdemo this might be WACSD), then a hyphen (-), then the model's key (model number/reference on that site) such as 123, and then another hyphen (-) and finally her model number on this Wacs installation such as 345. Thus the page would need to be saved as WACSD-123-345 for this model.

You would then run chkmodel 345 to scan that saved page for new sets. Any icons found in WACSD-123-345_files would also be transfered to the model's icon directory in icons in the site download directory (eg /var/spool/wacs/download/wacsdemo/). This naming convention is a little cumbersome and exposes more of Wacs's internal workings than is strictly desirable, and we do plan on addressing that in a future release. Right now we want to get the technology available to people who want to use it on sites where automatic download is not supported.

The refresh command is designed to be run by a nightly automatic job (aka crontab and calls chkmodel with the appropriate arguments to check a specific number of models each night. It limits itself to just a few so as to not be a "bad citizen" and outstay it's welcome. Refresh does actually use some fairly carefully designed metrics to optimise the way it looks for models, biasing it's checks towards those who are receiving regular updates and within those selecting those that have gone longest since the last check. It is generally pretty thorough in what it does.

The getarc command completes the picture by actually downloading the sets previously highlighted by the combination of refresh and chkmodel. Once getarc has obtained the necessary zip archive or movie file, it marks the set as pending at which point it can be unpacked using the standard Wacs unpack and placement tools invoked from either the download list or the model page (full version).

Again it is normally expected that getarc will be run at a quiet time of night by the crontab timed execution system.

The wacsdnlnext web app is designed to assist you and guide you through downloading sets from those sites where getarc is not suitable for use. Detailed instructions on using it can be found in the reference section, wacsdnlnext.

The Wacs Download Manager, wacsdnlmgr allows the resolution of some of the most common problems with download records. It's primary purpose is to allow manual changes to the status and set associations of download records. If you find a record you've downloaded has a broken zip file, you can use the download manager to list that download as Failed so it gets re-downloaded at some point in the future. If you have both models in a lesbian set having a download record in their own right for the set, you can use the download manager to mark the second download record as either successfully resolved or as a relationship entry. This usually depends on which model's name comes first - if the model upon the strength of whose record we unpacked it is the first model mentioned, the other(s) is a relationship entry; if not, both are marked as being successfull. It can also mark a set as being in error if the model featured in it is patently not the model to whom it has been attributed.

The easiest way to access it is via either the link on the download number on the detailed form of the model page, or on the entry in the download list. The first option via the model page only works while the download record is marked as unresolved (ie not Successful, Relationship Entry or Error.) To access a model record that is considered resolved, administrators will find a link on the download number listed in the details in the set info page.

If you're using a pre-defined site record for the Vendor site you wish to download from, you should have an easy time; just enable the site, add your password, and then add a few model details using the Wacs Model Manager and it should all start working. If you're creating a new Vendor site description, it can be rather more difficult.

The first thing you need to understand is how to set the Image and Video download id types to the correct values (vidtimg and vidtvid in the vendor schema - see section 3 of the programming manual). The actions take place in two places - first the chkmodel script must actually find the desired zip or video file name and create a download record requesting it be fetched. Second, the getarc script must actually perform the necessary retrieval and saving actions. The following table details how the various values currently work:

Alternative values you may see invoke custom code designed for specific sites only which are not expected to be applicable to more general use. These typically include work-arounds such as re-navigating the lead-in web pages as the final target URLs are liable to change, or guess that given a certain stem such as jennifer1.zip, additional zip files in this set will be called jennifer2.zip, jennifer3.zip and so on.

On Linux, MacOS X and other Unix like systems, the automatic execution system is known as cron and it's operation is managed by a somewhat cryptic program also called crontab. Normally cron will be running already since it is used by the operating system itself for housekeeping. It is important to understand that crontab does not "wake up" a machine that is switched off or suspended, and so setting to run an overnight job when you turn it off each evening as you go to bed will not prove useful because the job will never run. If the machine is left on, as most servers probably will be, a time in the early hours of the morning will probably be fine; if the machine is normally switched off overnight, choose a time when the machine has a good chance of being switched on. The tasks will run in the background and will not affect other users of the system particularly.

To make use of the automatic download feature, you need to enable two more programs to run at a suitable time: refresh and getarc. refresh scans registered models and checks for updates; getarc fetches a number of the updates that refresh has found. To enable the automatic scanning feature, you need to open a terminal window as a suitable Wacs administrator user and type:

% crontab -e

and add the following line to the crontab file:

 
22 0 * * *      /usr/local/bin/refresh

	Tip
	Crontab usually calls up the vi editor - you can recognise this by a tilde (~) symbol repeated all the way down the left hand side of the screen. This editor is a bit cryptic if you don't know it, but basically you need to press the lower case letter o, type the line above, press Enter, then press Escape and then type :wq. That should get the job done.

This will cause the refresh command to run at twenty-two minutes past midnight each day. Note that by default refresh will only check those models the Wacs system currently considers to be “Active”, ie those who have been found to have new sets within the last three months or so. An additional option to refresh, -a allows it to scan all models, including those marked as dormant. It is recommended to run this occasionally so that it will double check the dormant models at a much slower rate; you might wish for instance to check dormant models twice a week, and to do this you would add a second crontab entry of:

42 0 * * 2,5    /usr/local/bin/refresh -a

Once refresh has been run, any newly discovered sets will be registered in the WACS system - they can be examined using the Download list wacsdnllist or are listed per-model in the detailed model page wacsmodelpage. In order for them to be downloaded automatically you will also have to invoke the getarc command at some suitable point - I choose 6:45 in the morning. To set this up, you add the following to the crontab in the same way as above:

45 6 * * *      /usr/local/bin/getarc

The cron command when it runs will automatically email you with the details of what happened for each of the commands you've set it up to run in the crontab file.

The Wacs model manager can handle the XML files created by the wacsexport command, but initially only to a limited extent. If you consider the state of play as regards any given model and an XML file containing her details, you can see that there are five obvious states:

As of Wacs 0.8.3, the first of these is implemented in full - upload a Wacs model XML file and if the model isn't known, her record will be created. The third of these isn't really a problem for us although it might be nice to contribute back whatever additional information it is we know. The fifth of these is also relatively easy as the model manager just loads up the relevant model's record to say “Hey, we know her, and here's her details”. It is the second and fourth options that require more work and do not currently work as you might expect in Wacs 0.8.3 - at present if the model is known to Wacs, her record will simply be shown but no indication will be given of differences. The second will be the next part to recieve attention so that any field that is empty in our Wacs database will be filled in by values from the XML file.

Now that we've defined the terms of reference and you have some idea of what will work and what does not, lets just look at the steps involved in importing a new model record from the XML file.

It is quite a simple process to browse to whereever the XML file you want to load is, choose it and then click on the Upload Model XML File button. Do remember that the sample files we're using here can be found in /usr/share/wacs/samples/models on versions of Wacs installed by package, and in the samples directory of the unpacked tarball if installing from that.

	Warning
	The model manager XML import system uses existing IDmaps as a way of determining if it already has the model concerned in it's database. If you have a number of models with no IDmaps set, it could easily import a model twice. If in doubt, check your model directory before importing the XML file.

Here we see all the information from the XML file filled into the normal model update screen as we've seen before with the usual Summarise Changes button included. The only sign that this is an XML import is the title at the top of the screen (although hopefully that is screamingly obvious!). As usual, check it over, particularly looking at the model attributes which could be different on your system than on that which created the XML file in the first place. It's quite possible to change any of the values you disagree with here before creating the record. Once you're happy, just click on the Summarise Changes button to proceed.

We now see the summary of the information that the model manager is about to use in creating this record including the actual SQL is has written to do the deed itself. So long as you're happy with that, just go ahead and click on the Commit Changes button.

This is the final screen of the XML Upload conversation and as you can see it's fairly busy. The top bit relates to the actual creation of the model record itself and is the repeat of what happened before modulo any changes that have happened since (like someone else creating another model record in which case the model number we get will have changed). The next bit shows that we've added an identity map entry, in this case for KPC (Karup's PC), and the final piece mentions that it has also imported thirteen download records for this model. That is a part of the model manager code that is unique to the XML import feature - it can also be used to import new IDmaps and download records for an existing model but we'll discuss that feature in the next section.

The first example we're going to work through is simply to add a new IDmap to an existing model, in this case Sabrina and we're going to simply record that she is model no 1 on our demonstration site (called WACSD aka WACSdemo).

The first steps as shown above are simply to select the Identity Management radio button and type in the desired model number as before. All you then need to do is click on Find Model and you go straight to the IDmap page.

	Note
	For Identity Management mode the first three ways of finding the model work as you might expect from Model Update mode. The final one, uploading an XML file, doesn't do the same things at all and we'll cover that later in this chapter.

This is the list of existing IDmaps for Sabrina and as you can see she has quite a few! Of particular interest, and I know we've mentioned this before is that she has two on Sapphic Erotica (SE) and as you can see from the notes, the id changed after they did a site redesign. At the bottom of the screen, you see the web form we can use to add an additional entry. Something which we're now going to do:

This is simply a case of choosing the WACS Demo site from the pull-down menu and working out and adding in the model number or reference on that site as the key. If the site you want to add isn't in the list, it can be quickly and easily added using the Wacs Vendor Manager (described in the section called “Vendor Manager” in Chapter 11, Other Web Based Tools). Once entered, you just click on Add Idmap and you should see the following screen in confirmation:

We now have a new application for managing IDmaps and various links are provided in the Model Manager that link to it.

If you click on any one of the links to a given ID map in either the model manager or in the main full details modelpage, you can expect to arrive at the WACS ID Manager app wacsidmgr. This application allows you do manipulate the ID map - updating information on when it was last checked and changed, changing the key (if it has no associated download records) or marking it as obsolete (Gone) to permit the addition of a new current identity. As you will see in this example, it warns us when we are not allowed to modify certain aspects of the identity because of data integrity issues with download records that refer to it.

This application gives access to updating the changed and checked dates on a model's ID map for the first time. Previously only the automatic download chkmodel application could do this but as we've moved away from automatic downloading, this has become very necessary in maintaining reasonable data. You will notice it cautions against changing certain fields because of associated records. The normal proceedure is to mark a previous ID map as "Gone" and create a new ID for the same site but with the new details when a model has been renumbered by an upstream site.

We mentioned earlier that using an XML file in Identity Management mode was rather different from doing so in Model Update mode. For the purposes of this little demonstration, we've deleted all the download entries for Karup's PC (KPC) and the IDmap from Sabrina's records.

We're then going to proceed to import the supplied sample XML file (usually /usr/share/wacs/samples/models/Sabrina-18.xml) in Identity Management mode and you'll see what it does. The first step of course is to select Identity Management, browse for the XML file and click on Upload Model XML File.

As you can see, the model manager has found our record for Sabrina, and realised that we're missing the KPC identity and added it. Additionally it has discovered that the XML files has some extra download records it didn't have and has added those too.

	Note
	This trick only works correctly because Sabrina still has other uniquely identifiable (ie complete) IDmaps which can be used to associate her with the IDmaps from the XML file. That is we have some IDmaps that are common ground and indicate the link between our model Sabrina and the model detailed in the XML file.

	Note
	Unless you're using this from a script or similar, you will find that using the model manager (see Chapter 6, wacsmodelmgr - The Wacs Model Manager) is a much better idea. Almost all models created using addmodel will require additional work afterwards.

The addmodel script is a command line interface to creating models (and actually IDmaps as well). It takes the form of the command addmodel itself followed by a row of space separated name=value pairs. A simple example session with addmodel would look like this:

% addmodel name=Sarah hair=Redhead length=Normal titsize=Small pussy=Sh
aven attributes=shaven image=Sarah-1.jpg
Sarah is not known
Name: Sarah
Hair Colour: Redhead 
Hair Length: Normal
Titsize: Small
Attributes: shaven
Pussy: S
Aliases:
Usual Source:
Image: Sarah-1.jpg
Source:
RefNo:
OK to add (x for exclude) ? (y/n/x): y
Model number is 1
SQL: insert into models (modelno, mname, mhair, mlength, mtitsize, 
mattributes, maliases, musual, mimage, mstatus, mflag, mpussy, madded)
values( '1','Sarah' ,'Redhead','Normal','Small','','','','','A','N',
'S','9-OCT-2006')
%

It is worth noting that this program calls the GNOME "eog" Unix/ Linux image viewer to display the model icon, but could easily be changed to run display, xv or some other image viewer. The variable imgviewer at the top of the program controls this. It is not critical if it's not present or can't make a connection to an X-server. In most cases, addmodel will actually prompt for the major items of data if they are missing from the command line. It currently prompts for hair colour, length, titsize, pussy and attributes. If a source is specified but no usual, it will default it (in most cases).

At this point, it's probably worth visiting the Newly Added Models section of your WACS web site to check that Sarah has indeed appeared as intended. The following table lays out the names that addmodel recognises along with the legal values for each one - neither name or value is case sensitive except for the model name that is expected to be naturally capitalised, any value that contains a space should be enclosed in double quotes:

So long as you specify both a source site and a refno , the appropriate IDmap will be added too. Here is a more complex example of using addmodel:

% addmodel name=Erika hair=Brunette length=Long titsize=Tiny pussy=Sha
ven attributes='shaven tinytit tattoo' refno=eri046 altref=12475 sourc
e=AMK usual=amkingdom.com image=amkingdom/Erika-1.jpg
[...]
%

If we just review the extra entries used here, we'll see that the setting of attributes adds some extra information to aid searching by models - in this case, her unusual attributes that differ from what is "normal" are that she has exceptionally small breasts, a completely shaven pussy and a few tattoos.

The next keyword refno normal contains her model number at the source site; usually this is just a simple number. However in the case of the AMKingdom web site, there is a corporate wide “identity” which takes the form of three letters and then three numbers; in her case eri for Erika and 046 which we assume means she's the 46th model added with the first three letters of eri. Some of the other AMK group sites, such as ATK Premium navigate using the corporate id as the "model key", but the AMKingdom site (aka ATK Galeria) uses an older system based on a numeric reference. This is the altref specified here. We have also encountered a system (now thankfully gone from the site concerned) where the video index used a different model key from the image sets index. Generally having the dual key support available in the IDmaps just adds to the flexibility of the system. The source parameter gives us the “domain” in which these keys apply. In this case we're setting it to "AMK" for AMKingdom.com (which is now known as ATK Galleria but we've stuck with the old abrieviation). With these three specified, we'll be adding a record in the idmap table as well, mapping Erika with our model number 2075 to being “Erika” from AMKingdom.com with corporate id eri046 and model key 12475. Additional id mappings (for instance Erika also appears on ATExotics) can be easily added using the Identity Management feature in the model manager or can be added manually using SQL.

The next name usual merely makes a comment in the models table of where we usually find this model, in practice this usually means where we first found her! (This is defaulted to whatever source is set to if not specified.) The final attribute image specifies an icon for her (conventionally resized to 120x156) and in this case the icons have been subdivided by source site, so her icon appears in the amkingdom sub-directory. It also checks for the same name of file existing in the bigicons directory, and if it does, that is added too.

The addassoc command provides a way of manually adding an association between a model and a set. To use addassoc you need to be in the directory where the set directory itself is located - so if you're trying to connect a model called Sarah to a set in a gallery called nudity/gallery003 you would need to do the following:

% cd /home/wacs/images/nudity/gallery003
% addassoc Sarah Sarah_*
1. Sarah with Long Redhead hair and Small tits - model number=1
Name: Sarah
Hair Colour: Redhead
Hair Length: Long
Titsize: Small
Attributes: 
Aliases: 
Usual Source: 
Image: Sarah-1.jpg
RefNo: 1
Continue (y/n)? y
DB record found: setno 1, title: Sarah PinkDressNoPanties GardenBenchDildo
Added association between Sarah (1) and set 1
% 

	Tip
	A a set has to be known by WACS before you can associate it with any model, so in most cases the wacsgenimg command discussed below needs to have been run first.

If you now click on the link on Sarah's image or name on the Newly Added Models list, you should see her model-thumbs page with the new photoset featured on it. You might also wish edit the sets details using the set manager or to re-run the wacsupdinfo command to import any of the model's attributes (shaven, tattoo, etc) into the set details as well.

wacsdelset is passed a single argument of a directory name (which is assumed to contain an image set known to Wacs) or video file name and proceeds to delete the database records related to it in the correct order. Once complete it moves the files into the “delset_trash” directory of the download directory where they can be checked one more time before the files themselves are erased.

% cd /home/wacs/images/nudity/gallery003
% wacsdelset Sarah_PinkDressNoPanties_GardenBenchDildo
Set Number 14 to be deleted.
The set in Sarah_PinkDressNoPanties_GardenBenchDildo has been deregist
ered from Wacs.
The contents has been placed in /var/spool/wacs/download/delset_trash.
You may wish to check them and then remove them.
%

Running wacsgenimg is actually very simple, to import a tree of file directories (say /home/wacs/images/redheads/smalltits/Sarah) you just do:

% wacsgenimg redheads/smalltits/Sarah
[...]
COMPLETED: 12 new records inserted, 7 updated.
Calling make_index() with redheads/smalltits/Sarah
% 

In this example, wacsgenimg discovered 19 directories containing image files in the directory specified, 7 of which it already knew about and 12 of which were new to it. This is normally detected by the presence of a hidden file called .info which gives the basic set number information for each set within each directory. When the web interface is used, the Wacs placement manager (see Chapter 8, wacsplacemgr - The Placement Manager) creates a file in the directory called .unpack which wacsupdinfo uses to gain clues about the model featured, the download record “satisfied” by this set and so on. If this file is found, wacsupdinfo reads it and uses the values contained therein - if not, it tries a few other heuristics to determine what it's looking at and if all else fails just simply creates a new set without any model or download associations.

These heuristics vary by source site but basically resolve around looking for an “unsatisfied” download record with a known filename stem that matches the files found in the directory being considered. When it finds such a match, it will retrieve additional information like model number, set type, source site and photographer from the download record and merge that information with what it can determine from the name of the directory and the model's attributes. The download record will be marked as having been successful and will disappear from the model's detailed page. This method really only works when the image file names are long and quite structured in their naming but this is the case for a surprisingly large number of sites.

If a set is added without any associations, it can quite simply be used without any model associations or you can manually add the associations using the appropriate addassoc command. As mentioned in connection with the discussion of set naming, certain keywords are recognised within the directory name and used to define various special attributes in the default metadata for the set. Generate can recursively scan from the top of the images tree (or from any point on the sub-tree), but probably best avoided if you have a large number of directories in the system.

The wacsgenvid command performs much the same functions as the combination of wacsgenimg and wacsupdinfo for the importation of video clips into the Wacs system. It actually also includes aspects of the wacsupdinfo program but re-written for the video context. However the video naming convention is often a lot simpler and what metadata there is in inferred from the download record as very little information can be gleaned from the name of the file itself. In the case of videos, the .unpack mechanism used by the Wacs Placement Manager (see Chapter 8, wacsplacemgr - The Placement Manager provides the best way of getting metadata about video sets into Wacs.

	Note
	Although the relative pathnames appear the same, wacsgenvid operates in a parallel space under the videos tree in the file system. Additionally icons are automatically referred to by the same pathname but in the vidicons directory. Therefore for sarah01.mpg in videos/redheads/smallbreasts/Sarah , you would place the corresponding icon file as sarah01.jpg in vidicons/redheads/smallbreasts/Sarah.

wacsupdinfo is actually what does most of the hardwork for wacsgenimg including all of the database interactions. If called via wacsgenimg, the icons will be made first - if called directly, no icon manipulations will be undertaken. When the placement manager wants to do two passes of the wacsupdinfo process (in order to merge in model attributes and add additional models), it normally uses the direct wacsupdinfo first and only generates the icons on the second pass through (using wacsgenimg instead.

The wacsvidcomb is only really used for one specific type of set - a video set that was split into several smaller files for downloading. This command allows you to create a combined, cached copy of the multiple files as a single full length video clip. It only applies to video clips and can only be used when the various clips have been correctly marked up with the wacssetmgr (Wacs Set Manager web app) as being a primary and then continuation files. Additionally the download name for the set has to be specified - this is not the same as the name of the video file within the Wacs video files tree (although it can be if you wish).

With these pre-requisites done, the wacsvidcomb command is executed with the set number of the primary set. This will create a video of the whole video in your process directory of the unpack area. Where possible, the skip frame value will be used to try and remove any unwanted conformance slates from the later video clips. Note that the value used here is that of the sskipfr field of the sets data table. When MPlayer's mencoder is the conversion utility used (current default for Linux), the skip frame value is considered to be the number of i-Frames to be skipped. Many of the conformance slates are a single i-Frame sequence prepended onto the video, therefore a value of 1 is sufficient for a full removal. Obviously the exact rules for each source have to be determined by experimentation.

Once wacsvidcomb has succesfully run, you will need to also run the wacscachectl command to relocate the compilation movie from your process directory into the appropriate place in the web tree.

The wacscachectl command is responsible for managing the caches in the web tree for wacs sets. This only comes into effect when the UseDirect option is enabled, but it allows the direct downloading of video or zip files from the webserver bypassing the slower and less flexible wacszip system. Where a video set is a single file, this will create a symbolic link in the web tree; where it is a compilation, it will site the file created by wacsvidcomb in the appropriate place and create the necessary links to make use of it in preference to the raw version.

The normal invocation of this command is:

wacscachectl --create setno

The wacsupdstat command is there to ensure that a model's record is kept up to date with respect to the sets she is associated with. This is done because the model record actually keeps some basic statistics about the sets, number of images and video clips and types of activity featured in those sets in order to better describe the model and her activities (on camera). Of course, much of this information is ultimately derived from the sets she features in; for instance, if she features in a lesbian set, the assumption is that she does lesbian scenes on camera! Obviously examining every set each time a model page is loaded is unlikely to be very practical, so the schema design has this data cached within the model record.

Generally wacsupdstat needs to be run after each time updates are made to the Wacs collection, but in practice it's probably easier to simply configure it to run once per day. To do this we once again make use of the cron timed execution facility (described in the section called “Configuring Automatic Download” of Chapter 14, The Download System). In this example, it is being set to run at just after midnight (modulo the advice above about making sure the machine will be likely to switched on at that time):

% crontab -e

and add the following line to the entry:

15 0 * * *      /usr/bin/wacsupdstat

In Wacs 0.8.6, wacsupdstat (back then called updatestats) was upgraded to produce a summary on the standard output of what has changed. It mentions who has new sets, new types of sets and what totals they've now reached - this is a nice management summary for the in-house team. In fact, we decided it was so useful that is should be possible to share it with the wider user community. As a result in WACS 0.9.0 onwards there's a new blogging feature in WACS and the first thing to make use of it is none other than wacsupdstat.

The blogging feature is not enabled by default, but if you add the line: <updatestats>blog:notes</updatestats> to the layout section of the main wacs configuration file each time updatestats is run (and finds changes of course), it will post it's update report as a blog entry as well as emailing it to the WACS site administrator.

With the addition of the blogging feature in wacsupdstat in Wacs 0.9.0, facilities were needed to manage the blog entries which would otherwise grow rapidly. Additionally the user interface to reading the automatic blog entries created by wacsupdstat also provides for feature articles as well as simple blogs. There also needed to be a way to create these. This is all provided by the new wacsblogctl command.

wacsblogctl supports three main modes of operation in the initial version in Wacs 0.9.0 - --dump for exporting blog entries, --load for creating them from an HTML file and --purge to clean out old entries from the blog database. The --dump operation takes one more argument, the record number of the first record of the blog - the blog entry will be written to a file called blog-B-12.html where blog entry no 12 is a standard (B-type) blog entry.

The second operation, --load needs at least one more argument, the file name to read. It can also take --feature or --article which specifies it's an article and increases it's active life to three months instead of just one. A corresponding --blog specifies it's a standard blog entry (the default for now). You can also specify an author with the --author= option. The file that you load is a very simple HTML page and can be created with any standard HTML editor/composer of your choice. The first line up to a >p< paragraph break mark is assumed to be the title. The rest of the document is considered to be the body of the blog. If you include references to standard WACS icons (probably via dragging and dropping in your HTML editor), they will be condensed into the more portable #WACSMTHU# style substitution variables before being stored into the database.

To help clarify this, take a look at this example blog entry HTML document:

<html>
<head>
<title>Output of my HTML editor</title>
</head>
<body>
<b>Teen Beach Babes</b> by John
<p>
<img align=left src="#WACSIMG#/std343.jpg">Join our gorgeous model
<a href="#WACSMTHU#/23">Sarah</a> and all her friends down on
the beach peeling off their colourful bikinis so their lovely bodies feel
the warmth of the sun all over.
Come over to <a href="#WACSILIST#/cgroup=12"> for our best seaside
sunshine fun!
</body>
</html>

You note we've used the #WACSIMG# method here, but you could just as easily drag and drop images and links from an open web browser (assuming your editor supports that) instead - just make sure you've switched OFF usedirect mode in the Preferences program first. Now assuming you've called this file beach.html, you would use the following to make it into a feature blog article:

wacsblogctl --load --feature --author=John beach.html

The final operation, --purge simply deletes those standard blog entries that are now pasted their expiry date. If you also want to delete old feature articles, then add --all after the --purge command.

As we discussed back in the chapter on the Wacs Set Manager (Chapter 9, Wacs Set Manager), there is a potential catch 22 scenario when trying to mark a set as featuring a particular type of attire. This is that the pulldown menu will only offer you types of attire that have been previously used in another set. The usual way of dealing with this is to add a new keyword that will match that word and therefore create the new category of attire for you. If for some reason you didn't want to do this, you can use SQL to create a new attire entry that will appear in the pulldown menu.

For example, maybe you have a thing for ripped denim jeans and want to add a new attire category of Ripped Jeans to the possible options. You've just added a set which features ripped jeans and it's set number 14. The SQL command you would need to update set 14 to this new attire would be:

SQL> update sets set sattire = 'Ripped Jeans'
  2  where setno = 14;

1 record updated.
SQL> commit;

Commit complete.
SQL> quit

Once this has been done for set 14, Ripped Jeans will appear in the pull-down menu in the set manager for subsequent usage.

If you want to be able to move a record sensibly between different hosts via the migration tools, it really does need some kind of download record to uniquely identify it. As we've already seen back in the section called “Self Referential Download Records” there is now (as of Wacs 0.9.1) a web app to simplify this process, but it's still worth reviewing how we might do the same thing manually. It is a fairly simple matter to create a new download record for this purpose using SQL. The first step is to find out what the highest currently used download number is which can be done with this query:

sql> select max(downloadno) from download;

	2672

1 row selected;
sql>

With this duly determined, add one to the value (in this case 2672 becomes 2673) and use that in the SQL query you create. You will also need the related model number, which for the purposes of this illustration will be 2249 for a model called Sarah. The next value is XYZ which is the site id for an imaginary site called XYZ. The next value “V” is the value for the type of the file - V is for Video Clip, I is for image set. The next value is the set key which is the number obtained from the URL from the originating web site if possible or if not using the name of the video file itself as here. We then give it a name and repeat the name of the video file as the “archive” that this download record is expected to deliver.

sql> insert into download (downloadno, dmodelno, dsite, dtype, dsetkey,
   > dsetname, darchive)
   > values( 2673,2249,'XYZ','V','sarah04.mpg',
   > 'Sarah - Pink Dress - Garden Bench','sarah04.mpg');

1 row added.
sql> commit;

commit complete.
sql> quit

	Tip
	There is of course a web app for doing this! It's called wacsdnlreg and is available on the Maintenance menu of the front page when in administrator mode as Register Download.

One scenario that we do encounter from time to time on our large scale test system is where we discover after the event that two models we have listed separately in the database are actually one and the same girl. After making absolutely sure that we are talking about the same person (and hopefully making a note in the Distinguishing Marks field in the model record about how we confirmed that), we need to make it clear in our own minds what we're going to do.

This involves making a decision on which of the two model records we're actually going to keep and then checking the one that we intend to delete for any pertinent information, such as biographical data, which is not contained within the record we intend to keep. We can of course easily use the Model Manager (see Chapter 6, wacsmodelmgr - The Wacs Model Manager) to do this.

In the example we're going to work with we've discovered that Dianne from Sapphic Erotica who is our model number 163 is also Lena from ATK Galleria who is our model number 2474. We've taken the decision to retain her lower model number of 163 and delete the new addition, namely 2474. We've already copied across the extra biographical information that we had on the “Lena” record, and in fact we decided that we preferred the headshot we had of her from ATK Galleria and so modified that too. These are all very simple to do using the Model Manager, so we'll not cover the exact steps taken again here.

The first step we're going to take is to move the identity record for Lena over to Dianne so that future references to Lena on ATK Galleria automatically summon up Dianne's record. We do this with the following SQL command:

SQL> update idmap set imodelno = 163 where imodelno = 2474;

1 row updated.

SQL>

For the next step we're going to change the sets that we have marked as having Lena in to being marked as having Dianne in. This is actually quite easy to do because Wacs doesn't depend on the name that we have in a set record in anyway - it's merely a matter of convenience. Even after Lena's records have become Dianne's, there is no problem with her still being called Lena there. In someways that is desirable because it retains the connection with what she was called on the site where those sets came from. In other ways, it's very confusing as in “Who is this Lena girl who keeps appearing in Dianne's sets?”. We'd definitely recommend adding the name Lena to Dianne's aliases list in the model record because the top of the model page will then say about Dianne “Sometimes also known as Lena”. If you want to change the title of the set, you can easily do this with the Info Manager (see the section called “Managing Additional Information”). As a byproduct of changing the name using the Info Manager, the other fields in the set database that have model info in them will also be updated.

SQL> update assoc set amodelno = 163 where amodelno = 2474;

11 rows updated.

SQL>

While these two updates have changed most of the user visible entries, the are actually three more changes we could have to make. There are in fact five database tables that make reference to model numbers and all of them do need to be updated to match each other. These are:

This is where you have to know your database. The last thing you want to do is to leave a record lying around refering to something that no longer exists - that's extremely bad practice and is almost bound to cause some web application to fall over. Most databases simply won't let you do this - it's known as enforcing referential integrity - but unfortnately MySQL 5 in it's standard form is not one of them. This means you could easily delete a model who still has some download records or tags (individual elements of a search) still attached to them. Allowing this to happen is just storing up horrors for later.

As a general rule, it's best to try and change the model numbers in each and every database table that might contain them and just accept that in some cases there may well be nothing to do. An update that does nothing is really not a problem to any SQL version we've ever encountered. So we proceed with the next three steps on the basis that it's quite possible that they'll do nothing. Just understand that it's better to execute commands that often seem to do nothing than to end up with the chaos caused by connections left hanging. If you know your database well, and know it reliably enforces referential integrity, then you could skip those you know have no entries in them but we don't recommend this.

So we reach the third step, that where we move the download records, and remembering that these are an identification of which set is which in a portable way even when we have no plans to use the download system. In fact, it's good practice for commercial sites to allocate download records to their own sets to ease future server-to-server migrations and the like. Anyway, here is the SQL we need for this:

SQL> update download set dmodelno = 163 where dmodelno = 2474;

14 rows updated.

SQL>

Now on to the fourth and fifth steps, which we'll do together which are most likely not to find anything, updating the tag and connections records:

SQL> update tag set tmodelno = 163 where tmodelno = 2474;

4 rows updated.

SQL> update conn set cmodelno = 163 where cmodelno = 2474;

0 rows updated.

SQL>

So as you can see, in the above example it turned out that we did actually have Lena tagged in no less than four different saved searches, so it's just as well we updated them. The final step is to delete the old model record and complete the model merge process. It's good practice to include a commit at the end of the process - on a good relational database like Oracle, none of the other steps will have actually have been done to the database itself until that final commit is done. The beauty of this is that all of the actions will be taken at exactly the same time and no one browsing the Wacs site at the time will find a half-moved state - the change will literally happen in an instant despite the fact that we've been checking and composing the queries for probably a couple of minutes at least - quite possibly longer if you're reading this document at the same time. The alternative to using commit is to type rollback; which will undo all the changes. Unfortunately in MySQL 5 the commit and rollback functions, while present, don't work quite as they should. We can only hope that they will improve with time and further development.

SQL> delete from models where modelno = 2474;

1 row deleted.

SQL> commit;

Commit complete.

SQL> quit

So there we are. The two model records for SE's Dianne and ATK's Lena are now one and the same and we have a better quality entry for this lovely Ukrainian blonde in our database. All in all a good result.

This web application is designed to duplicate the text-based addmodel script and additionally provide a tool for updating model records and identity maps (jobs that previously had to be done directly in SQL). If you have administrator role defined for your account (see the section called “User Class”) it will appear on the Maintenance menu of the front page and as a link from each model's index page. When used from the model index page, it updates the model's details - used from the Maintenance menu it can add new models and idmaps as well as modifying existing model's records.

When called from the maintenance menu (or directly) it offers you two modes - Model Update or Identity Management - and three ways of finding the model to work on - by model number, by site and their id on that site or by name. If you choose name, both the main name and aliases in the models schema and the per-site idmap name will be searched and a selection of headshots and details of models with a similar name offered. You are also given the option to create a new model (if in Model Update mode - you can't create an IDmap for a model that doesn't exist!). This will allow you to create a new model or add a new idmap to an existing model. In the Wacs 0.9.2 release, it is now possible to edit existing IDmaps as well as model details; you can also enter directly into ID management mode for a specific model by using id=modelno in the URL.

The Wacs Set Manager, wacssetmgr allows the updating of set attributes through a web-based GUI. You get to it by clicking on the "rating" link on the model pages - this link is only offered to users in the administrator list. It can alternatively be invoked directly with the set number in the URL, for instance to edit details for set 12345, you'd give the URL ending with wacssetmgr/12345 . This presents a startforward web form through which you make your changes, click Summarise Changes and you'll see a list of what you've changed; if happy with it, click on Commit Changes to make those changes in the database.

The Wacs Info Manager, wacsinfomgr is effectively a partner for the Wacs Set Manager that provides for editing the more nuts and bolts fields within the sets table. One of it's major features is the ability to rename and relocate sets, but it covers several other areas including official and additional icons, textual descriptions and USC 2257 attribution management. It is invoked simply using the set number as a parameter in the URL, so to edit set no 12345 you give a URL ending with wacsinfomgr/12345.

The Wacs Icon Manager, wacsiconmgr is similar to the wacssetmgr and wacsinfomgr in that it focuses on managing a single set. In this case, it's focus is on the icons related to the set itself - the standard icon, the official icon, and any supplied additional icons. It is typically invoked with wacsiconmgr/12345.

The Wacs ID Manager, wacsidmgr works with the wacsmodelmgr to allow the updating and editing of IDs - the links between models and sites. Adding new ones is the province of the Model Manager, but all other alternations are done using the wacsidmgr. It is typically invoked with wacsidmgr/id123 where 123 is the ID reference number for the link between a model and a specific site.

The Wacs Unpack Manager, wacsunpackmgr is used to unpack downloaded zip or video files so that they can be examined, described and imported into the Wacs system. This can be done by one of three methods: taking a downloaded set from the Wacs download area, by uploading a zip or video file through a web browser, or by copying it from a specified directory on the Wacs server itself.

The Wacs Placement Manager, wacsplacemgr is used to place the unpacked set into the wacs image or video clips archive, naming it appropriately for it's content. The name you give it is then scanned for keywords which are used to make an initial first guess at the appropriate attributes to mark the set up with. These can be modified and improved using the wacssetmgr - Wacs Set Manager at a later time.

The Wacs Assocation Manager, wacsaddassoc is used to add new associations between models and sets. Its functionally is almost identical to the text-based addassoc utility but is somewhat easier to use being web-based. wacsaddassoc offers you three choices for the method of selecting the target set - a specified set number, a pull-down list of recently added image sets and a pull-down list of recently added video clips. Similarly it offers you three ways to select the model to be associated with the set: by specifying her model number, by selecting from a list of recently added models, or by searching for her by name.

Newly introduced in WACS 0.8.5, the wacsconnmgr provides a long needed interface to creating and adding to connections. The initial version is somewhat simplistic but never-the-less allows connection sets to be created quickly and easily. It is very similar in operation to wacsaddassoc in offering you a number of pull-down menus to select from recently added sets or models. It also provides for direct entry of set numbers and model numbers.

The Wacs Vendor Manager, wacsvendmgr is used in the maintenance of the vendor database which is used by some of the model and set display pages to profer a link back to the original site and heavily in the download infrastructure. It can display, update or create new vendor records in the vendor database. When first invoked, it will offer a choice of vendor sites which have been preloaded into the system using the the console tool vendor table population command, vendors.xml. A number of sample vendor records are distributed in the XML file, vendors.xml which is read by the the section called “The wacspop command” command. This is typically done automatically by the easyinstall command when WACS is installed, or manually if the RPM packages were used.

The Add A New Vendor option gives a simplifed form for the basic details; once created the record should be modified to add whatever extra information is also known. Please contribute details for any good quality sites you know of to the authors to be included in a future version.

Please note that the URLs stored in the vendor database include a number of keywords sandwiched by hash (#) symbols which are substituted for by WACS before calling the described page. The current recognised keywords are:

The Wacs Photographer Manager, wacsphotmgr is used in the maintenance of the photographer database which is used by many of the model and set display pages to profer to work by the same photographer. It can display, update or create new photographer records in the photographer database. When first invoked, it will offer a choice of existing defined photographers, and an option to add a new one. As with vendors, there is a corresponding command line utility called photographers.xml which will import the provided photographers.xml sample collection.

The Wacs Keyword Manager, wacskeywordmgr is used for viewing, adding and amending keyword look-up rules used by the updateinfo command in determining the automatic values for a named set. It does not take any URL arguments, you merely scroll through the list presented, tick the adjacent tick box and then click on Edit or Delete. To add a new keyword, simply click on Add. Scores for each attribute that is infered from the keyword start at 1 for least likely up to 9 for most likely. To investigate how a given set of attributes produced the result it did, set the debug level for tool_updateinfo to something like 5 and the score card used will be displayed.

	Note
	This is new in WACS 0.8.5 - it is not available in previous releases

WACS has two options for how to authenticate users for access to the collection - hostauth which authenticates users by asking the web server host itself and database which uses the user database table within the Wacs database itself. The usual default for Wacs has been to use the hostauth method which works well for both small systems with local users and for bigger systems with distributed authentication like NIS, LDAP or even Active Directory. Where this is not so useful is for commercial sites where all you want your users to access is the WACS-managed collection and nothing else. Here the extra overhead of maintaining a second independant authentication mechanism is a positive boon for security and demarcation.

The wacsusermgr webapp by default creates new users with the next available userid, but if passed a user id on the URL will allow you to edit an existing userid. With this application you can manage user accounts and access rights with reasonable ease.

Tip

What you will notice about wacsusermgr is that some of the functionality is not available - these pieces handle aspects such as address and contact info, automatic sign-up, renewals and referral commissions. The WACS developers do want to see some return on their work and felt the best way to do this was to offer an added value product for the really serious commercial sites and felt the absense of these kind of features was no great loss to the regular free software community - the system is fully functional without it. As a result, a commercial add-on package including the plug-in for wacsusermgr, auto sign-up and customer relationship management features called WacsPro is available through Bevtec Communications Ltd. All the relevant data structures we use are distributed as part of the standard Wacs distribution, so you are at liberty to write your own plug-ins if you wish to. The Wacs developers will even accept and welcome contributions back into the Wacs source tree in this area if people wish to submit them.

	Note
	This is new in WACS 0.8.5 - it is not available in previous releases

This is a straightforward index of the current user accounts along with a link to allow you to edit each of them using wacsusermgr. wacsuserlist is a bit simplistic and has no search features but should be very usuable up to about a hundred users or so. A more advanced version with search, auto-reminder and data analysis features is part of the WacsPro toolkit available as a commercial add on from Bevtec Communications Ltd .

The Wacs Download Manager, wacsdnlmgr allows the resolution of some of the most common problems with download records. To invoke the download manager for download record 1234, call wacsdnlmgr with wacsdnlmgr/download1234.html. The wacsmodelpage will automatically link to this page for users with role “admin” in the access control lists.

This command, introduced in WACS 0.9.1, makes it much easier to create a new set download record. This can either be used to create an identity record which helps with moving sets between installations, or simply to make it easier to unpack sets downloaded from a site that can't be automatically parsed.

This gives an overview of the current state of the download activity over the last two weeks. It's primarily informational although it does link to the download manager to allow modification of the download records.

For some web sites, due to their security measures, it is not possible to perform an automatic download. For these sites, it is possible to have the Wacs download system parse a saved version of the model's index page to compare the set numbers the system knows about with the new version of the page to see if any new sets have been added. If there are new ones found, in most cases the information found is incomplete - mostly it is missing the actual URL (Web Address) for the downloadable zip or movie file - making the download record incomplete. The wacsdnlframe web application splits the web page into two halves - the top half has some input fields; the bottom half has the relevant set page from the site displayed in it.

To make use of wacsdnlframe you find the link to the zip or movie file, do a right mouse click on the link and choose Copy Link Location. You then move up to the input field in the top half of the page, and simply paste the saved URL into it. You then click on the "Complete Download Record" button and the URL for the set is saved into it's download record and the status updated to show that it is now a complete record and usable for a download.

The wacsdnlnext command provides a web-based alternative to the standard command line download tool getarc by creating a web page containing currently pending downloads. It gives both where a set should be saved and a link to each set to be downloaded. It also provides a tick box which can be ticked when each set has been downloaded - it will then check for the presence of the downloaded files and if they're present, mark the download record as pending unpacking.

The recommended sequence for using wacsdnlnext is to select the full pathname where the file should be saved, copy it into the paste buffer, then right click on the link on the archive name and choose Save Link As - in the dialog box that pops up, you then paste the destination directory from the paste buffer. Finally you tick the done box once the download is complete. Once you've done all the downloads you intend to in this batch, you can click on the Update To Do List button at the bottom and the ticked downloads will be checked and if present and of a reasonable size, their download records will be updated to indicate that they have been downloaded.

	Tip
	There is no problem with downloading out of sequence. You can do all the images first for instance and then leave the videos running while you do something else. Just tick the ones you've done and wacsdnlnext will do the rest.

Since WACS 0.9.0, there has been a very simplistic blogging system built into WACS. The main use of it so far has been for the updatestats tool to post an article detailing the latest updates but highlighted in a model-centric rather than set-centric way. This behaviour is optional and is configured through the standard wacs configuration file. It is also possible to use the blogging system for other content of a more editorial nature.

It is this more editorial material and getting it into the WACS blogging system that the wacsblogctl application is primarily concerned with. You are expected to prepare the material within a normal HTML editor of your choice and then save the resulting article. It is this file that wacsblogctl processes and turns into a new blog article. The wacsblogctl supports modes of --load, --dump, --purge and --help.

When you are composing a blog entry, the first line of your simplistic HTML page will become the title up to the first paragraph break mark, ie <p>. All the subsequent text will be the body of the blog entry. You can use all normal HTML directives including tables, font settings, etc and you can include links to wacs apps and icons. You can either give the full URL with any <img src= or <a href= tags you wish to add e.g. http://myserver.example.com/cgi-bin/wacs/wacsimg/mini343.jpg or you can specify it with the standard wacs configuration and menu file notation of #WACSIMG#/mini343.jpg.

For more information on how to use this, please see the section called “The wacsblogctl Command”.

wacsvidcomd which is discussed in some detail in the the section called “Content Caching Mechanisms” section of the chapter on Chapter 13, When Using Wacs For Hosting provides a database driven simplistic video editor/encoder that creates edited compilation videos from segmented video clips appropriately marked up within the Wacs database.

The wacscachectl takes a mode and set number as an argument and prepares cached content for that set within the WACS content caching mechanism introduced in WACS 0.9.1. At present only --create is accepted as a mode, and a set number as the argument. For video files, the cooked compilation file if needed is expected to have already been created using wacsvidcomb. Please see the section on content caching in Chapter 13, When Using Wacs For Hosting for more information

There are currently five XML file types that understood by the wacspop command and they are:

Here wacspop reads the vendors.xml file and populates the vendors table with some useful example site (aka vendor) description records. These provide examples on how to configure the automatic download system as embodied in the chkmodel and getarc programmes, and should be directly usuable for any of the sites listed as soon as you add an appropriate username, password and subscription expiry date and set the subscription active.

Here wacspop reads the photographer.xml file and populates the photographer table with some useful example records. These will typically be photographers whose work has been encountered on a number of different websites and who have a “corporate” presence on the web. An initial selection of the most active circa 2011 is included in the XML file.

Here wacspop reads the keywords.xml file and populates the keyword table with some example keyword settings and priorities. There are about one hundred and fifty entries in the distributed file, which should provide some ideas on how the system works. Basically each keyword has entries for attributes, attire, locations and set types that it may provide clues to - each one of these is scored. The trick is to set the scores such that the presence of a sofa implies it's in a lounge, unless something else which binds stronger is also there. So if a photographer drags a sofa out into a garden for a given shoot, the "Garden" means Garden, Outside and takes preference over the "Sofa" means lounge rule. Take a look at Chapter 4, Naming Sets In WACS for more information and also use the wacskeywordmgr to have a look at the definitions we have already created for you.

This is new one for Wacs 0.9.0 as the attributes table wasn't actually used in any previous release. One of the major changes in Wacs 0.9.0 is that the attributes mechanism is now entirely within the database (apart from some fallback code to keep old programs functioning). This file provides the initial load for all the standard attributes and their icons, a couple of new basic ones and a bunch of so-called new extended ones. As a result of this, it now becomes possible to add new attributes at will while other attributes can be recognised but not used if you so desire.

Unfortunately although we do plan to add a GUI tool to allow editing of the attributes database soon, it wasn't one of the priorities for the WACS 0.9.0 release and so isn't in this release. However if you read the details on the attrib schema in the Programming Manual and have basic familiarity with SQL, it's not that hard to add your own new definitions. This should be a marked improvement over the previous versions where adding new attributes involved editing the WACS module source code itself. This is also discussed in significant detail in the Chapter 18, Customisation chapter.

	Note
	If you loaded the sample data included with the earlier Wacs 0.8.6 release, you may want to delete that entirely as the final versions are somewhat different from those in the pre-release. If you haven't made any changes, the SQL command: delete from attrib; followed by a commit; and running wacspop with the Wacs 0.9.0 file will fix this.

This simple XML file creates three basic user accounts: root, support and guest to allow the initial setup of a WACS system that wishes to use database authentication of users. Please make sure you change the passwords on all three accounts once you have the WACS system operational. Anyone looking at the WACS code will know what these initial passwords are!

They are currently: root - Svjck981, support - uKiFt126 and guest - freebie. Leave them unchanged at your peril!