Ftp Web Hosting - J2Ee Hosting Sun Java Developing Blog

rest This argument should be coded in the

humphreyblogart — Sat, 29 Dec 2007 13:08:29 +0000

rest This argument should be coded in the same way as the flags field of the active file. This command is useful to change the moderation status of a group. Remove a Group Use the following syntax to remove a group: ctlinnd rmgroup group The argument is defined as follows: group The name of the group to remove. This command removes the specified newsgroup from the active file. It has no effect on the news spool. All articles in the spool for the specified group will be expired in the usual fashion, but no new articles will be accepted. Renumber a Group Use the following syntax to renumber a group: ctlinnd renumber group The argument is defined as follows:

/etc/crontab file, or (Tomcat web server) even better, create a file

humphreyblogart — Fri, 28 Dec 2007 19:10:25 +0000

/etc/crontab file, or even better, create a file suitable for the /etc/cron.d directory, if your distribution provides one. An example of such a file might look like: # Example /etc/cron.d/inn file, as used in the Debian distribution. # SHELL=/bin/sh PATH=/usr/lib/news/bin:/sbin:/bin:/usr/sbin:/usr/bin # Expire old news and overview entries nightly, generate reports. 150*** news news.daily expireover lowmark delayrm # Every hour, run an rnews -U. This is not only for UUCP sites, but # also to process queued up articles put there by in.nnrpd in case # innd wasn’t accepting any articles. 10**** news rnews-U These commands will ensure that old news is automatically expired each day, and that any queued articles are processed each hour. Note also that they are executed with the permissions of the news user. Managing INN: The ctlinnd Command The INN news server comes with a command to manage its day-to-day operation. The ctlinnd command can be used to manipulate newsgroups and newsgroup feeds, to obtain the status, of the server, and to reload, stop, and start the server. You’d normally get a summary of the ctlinnd command syntax using: # ctlinnd -h We’ll cover some of the more important uses of ctlinnd here; please consult the ctlinnd manual page for more detail. Add a New Group Use the following syntax to add a new group: ctlinnd newgroup group rest creator The arguments are defined as follows: group The name of the group to create. rest This argument should be coded in the same way as the flags field of the active file. It defaults to y if not supplied. creator The name of the person creating the group. Enclose it in quotes if there are any spaces in the name. Change a Group Use the following syntax to change a group: ctlinnd changegroup group rest The arguments are defined as follows: group The name of the group to change.

So that you can see what a control.ctl (Best web design)

humphreyblogart — Fri, 28 Dec 2007 02:24:18 +0000

So that you can see what a control.ctl file would look like in practice, here is a very short illustrative sample: ## Sample /etc/news/control.ctl ## ## Warning: You should not use this file, it is illustrative only. ## Control Message Handling all:*:*:mail checkgroups:*:*:mail ihave:*:*:drop sendme:*:*:drop sendsys:*:*:log=sendsys senduuname:*:*:log=senduuname version:*:*:log=version newgroup:*:*:mail rmgroup:*:*:mail ## Handle control messages for the eight most important news heirarchies ## COMP, HUMANITIES, MISC, NEWS, REC, SCI, SOC, TALK check- groups:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop newgroup:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop rmgroup:*:comp.*|humanities.*|misc.*|news.*|rec.*|sci.*|soc.*|talk.*:drop checkgroups:group-admin@isc.org:*:verify-news.announce.newgroups newgroup:group-admin@isc.org:comp.*|misc.*|news.*:verify- news.announce.newgroups newgroup:group-admin@isc.org:rec.*|sci.*|soc.*:verify- news.announce.newgroups newgroup:group-admin@isc.org:talk.*|humanities.*:verify- news.announce.newgroups rmgroup:group-admin@isc.org:comp.*|misc.*|news.*:verify- news.announce.newgroups rmgroup:group-admin@isc.org:rec.*|sci.*|soc.*:verify- news.announce.newgroups rmgroup:group-admin@isc.org:talk.*|humanities.*:verify- news.announce.newgroups ## GNU ( Free Software Foundation ) newgroup:gnu@prep.ai.mit.edu:gnu.*:doit newgroup:news@*ai.mit.edu:gnu.*:doit rmgroup:gnu@prep.ai.mit.edu:gnu.*:doit rmgroup:news@*ai.mit.edu:gnu.*:doit ## LINUX (Newsfeed from news.lameter.com) checkgroups:christoph@lameter.com:linux.*:doit newgroup:christoph@lameter.com:linux.*:doit rmgroup:christoph@lameter.com:linux.*:doit Running INN The inn source package provides a script suitable for starting inn at boot time. The script is usually called /usr/lib/news/bin/rc.news. The script reads arguments from another script, usually called /usr/lib/news/innshellvars, which contains definitions of the filenames and filepaths that inn will use to locate components it needs. It is generally considered a good idea to execute inn with the permissions of a non-root user, such as news. To ensure that inn is started at boot time, you should check that /usr/lib/news/innshellvars is configured correctly and then call the /usr/lib/news/bin/rc.news script from a script executed at boot time. Additionally, there are administrative tasks that must be performed periodically. These tasks are usually configured to be executed by the cron command. The best way to do this is to add the appropriate commands to your

The message field of each (Web hosting resellers) line can have

humphreyblogart — Thu, 27 Dec 2007 10:06:14 +0000

The message field of each line can have one of the following values: checkgroups This message requests that news administrators resynchonrize their active newsgroups database against the list of newsgroups supplied in the control message. newgroup This message requests the creation of a new newsgroup. The body of the control message should contain a short description of the purpose of the newsgroup to be created. rmgroup requests that a newsgroup be removed. sendsys This message requests that the sys file of this news server be transmitted by mail to the originator of the control message. RFC-1036 states that it is a requirement of Usenet membership that this information be publicly available because it is used to keep the map of Usenet up to date. version This message requests that the hostname and version of news server software be returned to the originator of the control message. all This is a special coding that will match any control message. The message field may include the following actions: doit The requested command is performed. In many cases, a mail message will be sent to the administrator to advise them that the action has taken place. doit=file This is the same as the doit action except that a log message will be written to the file log file. If the specified file is mail, the log entry is sent by email. If the specified file is the null string, the log message is written to /dev/null and is equivalent to using the unqualified doit action. If the file name begins with a / character, the name is taken to be an absolute filename for the logfile; otherwise, the specified name is translated to /var/log/news/file.log. doifarg The requested command is performed if the command has an argument. If the command has no argument, the control message is ignored. drop The requested command is ignored. log A log message is sent to the stderr output of the innd process. This is normally directed out to the /var/log/news/errlog file. log=file This is the same as a log action, except the logfile is specified as per the rules given for the doit=file action. mail An email message is sent to the news administrator containing the requested command details. No other action takes place. verify-* If an action begins with the string “verify-”, then the control message is authenticated using PGP (or GPG).139 PGP and GPG are tools designed to authenticate or encrypt messages using public key techniques. GPG is the GNU free version of PGP. GPG may be found at http://www.gnupg.org/, and PGP may be found at http://www.pgp.com/.

Web hosting contract - purge This field allows you to specify the

humphreyblogart — Wed, 26 Dec 2007 16:24:39 +0000

purge This field allows you to specify the maximum time an article with an Expires header will be kept before it is expired. The coding of this field is the same as for the keep field. Our requirements are simple. We will keep all articles in all newsgroups for 14 days by default, and between 7 and 21 days for articles that have an Expires header. The rec.crafts.brewing.private newsgroup is our internal newsgroup, so we’ll make sure we don’t expire any articles from it: # expire.ctl file for the Virtual Brewery # Expire all articles in 14 days by default, 7-21 days for those with # Expires: headers *:A:7:14:21 # This is a special internal newsgroup, which we will never expire. rec.crafts.brewing.private:A:never:never:never We will mention one special type of entry you may have in your /etc/news/expires.ctl file. You may have exactly one line that looks like this: /remember/:days This entry allows you to specify the minimum number of days that an article will be remembered in the history file, irrespective of whether the article itself has been expired or not. This might be useful if one of the sites that is feeding you articles is infrequent and has a habit of sending you old articles every now and again. Setting the /remember/ field helps to prevent the upstream server from sending you the article again, even if it has already been expired from your server. If your server remembers it has already received the article, it will reject attempts to resend it. It is important to remember that this setting has no effect at all on article expiration; it affects only the time that details of an article are kept in the history database. Handling Control Messages Just as with C News, INN can automatically process control messages. INN provides a powerful configuration mechanism to control what action will occur for each of a variety of control messages, and an access control mechanism to control who can initiate actions against which newsgroups. The control.ctl file The control.ctl file is fairly simple in structure. The syntax rules for this file are much the same as for the other INN configuration files. Lines beginning with # are ignored, lines may be continued using /, and fields are delimited by :. When a control message is received, it is tested against each rule in turn. The last rule in the file that matches the message is the rule that will be used, so you should put any generic rules at the start of the file and more specific rules at the end of the file. The general syntax of the file is: message:from:newsgroups:action The meanings of each of the fields are: message This is the name of the control message. Typical control messages are described later. from This is a shell-style pattern matching the email address of the person sending the message. The email address is converted to lowercase before comparison. newsgroups If the control message is newgroupor rmgroup, this field is a shell-style pattern matching the news- group created or removed. action This field specifies what action to take for any message matching the rule. There are quite a number of actions we can take; they are described in the next list.

Password This field (Web design service) is optional and is the

humphreyblogart — Tue, 25 Dec 2007 23:14:16 +0000

Password This field is optional and is the password accompanying the username field. Leaving this field blank means that no password is required to post articles. Newsgroups This field is a pattern specifying which newsgroups the client is allowed to access. The pattern follows the same rules as those used in the newsfeeds file. The default for this field is no newsgroups, so you would normally have a pattern configured here. In the virtual brewery example, we will allow any NNTP client in the Virtual Brewery domain to both read and post to all newsgroups. We will allow any NNTP client read-only access to all newsgroups except our private internal newsgroup. Our nnrp.access file will look like this: # Virtual Brewery -nnrp.access # We will allow public reading of all newsgroups except our private one. *:R:::*,!rec.crafts.brewing.private # Any host with the Virtual Brewery domain may Read and Post to all # newsgroups *.vbrew.com:RP::* Expiring News Articles When news articles are received by a news server, they are stored to disk. News articles need to be available to users for some period of time to be useful, so a large operating news server can consume lots of disk space. To ensure that the disk space is used effectively, you can opt to delete news articles automatically after a period of time. This is called article expiration. Naturally, INN provides a means of automatically expiring news articles. The expire.ctl file The INN server uses a program called expire to delete expired news articles. The expire program in turn uses a file called /etc/news/expire.ctl to configure the rules that govern article expiration. The syntax of /etc/news/expire.ctl is fairly simple. As with most configuration files, empty lines or lines beginning with the # character are ignored. The general idea is that you specify one rule per line. Each rule defines how article expiration will be performed on newsgroups matching a supplied pattern. The rule syntax looks like this: pattern:modflag:keep:default:purge The following list describes the fields: pattern This field is a comma-delimited list of patterns matching names of newsgroups. The wildmat(3) routine is used to match these patterns. The last rule matching a newsgroup name is the one that is applied, so if you want to specify wildcard (*) rules, they should be listed first in this file. modflag This flag describes how this rule applies to moderated newsgroups. It can be coded with an M to mean that this rule applies only to moderated newsgroups, a U to mean that this rule applies only to unmoderated newsgroups, or an A to mean that this rule ignores the moderated status and applies to all groups. keep This field allows you to specify the minimum time an article with an “Expires” header will be kept before it is expired. The units are days, and are a floating point, so you may specify values like 7.5 for seven-and-a-half days. You may also specify never if you wish articles to stay in a newsgroup forever. default This field is the most important. This field allows you to specify the time an article without an Expires header will be kept. Most articles won’t have an Expires header. This field is coded in the same way as the keep field, with never meaning that articles without Expires headers will never be expired.

streaming This key determines whether streaming commands are (Web site layout)

humphreyblogart — Tue, 25 Dec 2007 07:24:33 +0000

streaming This key determines whether streaming commands are allowed from this host. It is a Boolean value that defaults to true. max-connections This key specifies the maximum number of connections allowed from this group or peer. A value of zero means unlimited (which can also be specified using none). password This key allows you to specify the password that must be used by a peer if it is to be allowed to transfer news. The default is to not require a password. patterns This key specifies the newsgroups that we accept from the associated peer. This field is coded according to precisely the same rules as we used in our newsfeeds file. In our example we have only one host that we are expecting to feed us news: our upstream news provider at Groucho Marx University. We’ll have no password, but we will ensure that we don’t accept any articles for our private newsgroup from outside. Our hosts.nntp looks like: # Virtual Brewery incoming.conf file. # Global settings streaming: true max-connections: 5 # Allow NNTP posting from our local host. peer ME { hostname: “localhost, 127.0.0.1″ } # Allow groucho to send us all newsgroup except our local ones. peer groucho { hostname: news.groucho.edu patterns: !rec.crafts.brewing.private } The nnrp.access file We mentioned earlier that newsreaders, and in fact any host not listed in the hosts.nntp, that connect to the INN news server are handled by the nnrpd program. nnrpd uses the /etc/news/nnrp.access file to determine who is allowed to make use of the news server, and what permissions they should have. The nnrp.access file has a similar structure to the other configuration files we’ve looked at. It comprises a set of patterns used to match against the connecting host’s domain name or IP address, and fields that determine what access and permission it should be given. Each entry should appear on a line by itself, and fields are separated by colons. The last entry in this file that matches the connecting host will be the one used, so again, you should put general patterns first and follow them with more specific ones later in the file. The five fields of each entry in the order they should appear are: Hostname or IP address This field conforms to wildmat(3) pattern-matching rules. It is a pattern that describes the connecting host’s name or IP address. Permissions This field determines what permissions the matching host should be granted. There are two permissons you may configure: R gives read permissions, and P gives posting permissions. Username This field is optional and allows you to specify a username that an NNTP client must log into the server before being allowed to post news articles. This field may be left blank. No user authentication is required to read articles.

The nntpsend.ctl file allows us to associate a (Unable to start debugging on the web server)

humphreyblogart — Mon, 24 Dec 2007 13:08:49 +0000

The nntpsend.ctl file allows us to associate a fully qualified domain name, some news feed size constraints, and a number of transmission parameters with a news feed site name. The sitename is a means of uniquely identifying a logical feed of articles. The general format of the file is: sitename:fqdn:max_size:[args] The following list describes the elements of this format: sitename The sitename as supplied in the newsfeeds file fqdn The fully qualified domain name of the news server to which we will be feeding the news articles max_size The maximum volume of news to feed in any single transfer args Additional arguments to pass to the innxmit command Our sample configuration requires a very simple nntpsend.ctl file. We have only one news feed. We’ll restrict the feed to a maximum of 2 MB of traffic and we’ll pass an argument to the innxmit that sets a 3-minute (180 second) timeout. If we were a larger site and had many news feeds, we’d simply create new entries for each new feed site that looked much the same as this one: # /etc/news/nntpsend.ctl # gmarxu:news.groucho.edu:2m:-t 180 # Controlling Newsreader Access Not so many years ago, it was common for organizations to provide public access to their news servers. Today it is difficult to locate public news servers; most organizations carefully control who has access to their servers, typically restricting access to users supported on their network. INN provides configuration files to control this access. The incoming.conf file We mentioned in our introduction to INN that it achieves some of its efficiency and size by separating the news feed mechanism from the newsreading mechanism. The /etc/news/incoming.conf file is where you specify which hosts will be feeding you news using the NNTP protocol, as well as where you define some parameters that control the way articles are fed to you from these hosts. Any host not listed in this file that connects to the news socket will not be handled by the innd daemon; instead, it will be handled by the nnrpd daemon. The /etc/news/incoming.conf file syntax is very simple, but it takes a moment to come to terms with. Three types of valid entries are allowed: key/value pairs, which are how you specify attributes and their values; peers, which is how you specify the name of a host allowed to send articles to us using NNTP; and groups, a means of applying key/value pairs to groups of peers. Key/value pairs can have three different types of scope. Global pairs apply to every peer defined in the file. Group pairs apply to all peers defined within that group. Peer pairs apply only to that one peer. Specific definitions override less specific ones: therefore, peer definitions override group definitions, which in turn override global pairs. Curly brace characters ({}) are used to delimit the start and end of the group and peer specifications. The # character marks the rest of the line it appears on as a comment. Key/value pairs are separated by the colon character and appear one to a line. A number of different keys may be specified. The more common and useful are: hostname This key specifies a comma-separated list of fully qualifed names or IP addresses of the peers that we’ll allow to send us articles. If this key is not supplied, the hostname defaults to the label of the peer.

Witems What to write: b (article bytesize), f (Windows 2003 server web)

humphreyblogart — Sun, 23 Dec 2007 20:06:46 +0000

Witems What to write: b (article bytesize), f (full path), g (first newsgroup), m (Message ID), n (relative path), s (site that fed article), t (time received), * (names of funnel feed-ins or all sites that get the article), N (newsgroups header), D (distribution header), H (all headers), O (overview data), and R (replication data). The param field has special coding that is dependent on the type of feed. In the most common configuration it is where you specify the name of the output file to which you will write the outgoing feed. In other configurations you can leave it out. In yet other configurations it takes on different meanings. If you want to do something unusual, the newsfeeds(5) manual page will explain the use of the param field in some detail. There is a special site name that should be coded as ME and should be the first entry in the file. This entry is used to control the default settings for your news feeds. If the ME entry has a distribution list associated with it, this list will be prepended to each of the other site entries before they are sent. This allows you to, for example, declare some newsgroups to be automatically fed, or automatically blocked from feeding, without having to repeat the pattern in each site entry. We mentioned earlier that it was possible to use some special feeds to generate thread data that makes the news- reader’s job easier. We’ll do this by exploiting the overchan command that is part of the INN distribution. To do this, we’ve created a special local feed called overview that will pass the news articles to the overchan command for processing into overview data. Our news server will provide only one external news feed, which goes to the Groucho Marx University, and they receive articles for all newsgroups except the control and junk newsgroups, the rec.crafts.brewing.private news- group, which will be kept locally, and the rec.crafts.brewing.poison newsgroup, which we don’t want people from our brewery seen posting to. We’ll use the nntpsend command to transport the news via NNTP to the news.groucho.edu server. nntpsend requires us to use the “file” delivery method and to write the article’s pathname and article ID. Note that we’ve set the param field to the name of the output file. We’ll talk a little more about the nntpsend command in a moment. Our resulting newsfeed’s configuration is: # /etc/news/newsfeeds file for the Virtual Brewery # # Send all newsgroups except the control and junk ones by default ME:!control,!junk:: # # Generate overview data for any newsreaders to use. overview::Tc,WO:/usr/lib/news/bin/overchan # # Feed the Groucho Marx University everything except our private newsgroup # and any articles posted to the rec.crafts.brewing.poison newsgroup. gmarxu:!rec.crafts.brewing.poison,@rec.crafts.brewing.private:\ Tf,Wnm:news.groucho.edu # The nntpsend.ctl file The nntpsend program manages the transmission of news articles using the NNTP protocol by calling the innxmit command. We saw a simple use of the nntpsend command earlier, but it too has a configuration file that provides us with some flexibility in how we configure our news feeds. The nntpsend command expects to find batch files for the sites it will feed. It expects those batch files to be named /var/spool/news/out.going/sitename. innd creates these batch files when acting on an entry in the news- feeds, which we saw in the previous sections. We specified the sitename as the filename in the param field, and that satisfies the nntpsend command’s input requirements. The nntpsend command has a configuration file called nntpsend.ctl that is usually stored in the /etc/news/ directory.

# newsfeeds file format site:pattern:flags:param site2:pattern2\ :flags2:param2 Each (Web hosting top)

humphreyblogart — Sun, 23 Dec 2007 03:17:33 +0000

# newsfeeds file format site:pattern:flags:param site2:pattern2\ :flags2:param2 Each news feed to a site is described by a single line, or may be spread across multiple lines using the \ continuation character. The : characters delimit the fields in each line. The # character at the start of a line marks that line as a comment. The site field names the site to which this feed description relates. The sitename can be coded any way you like and doesn’t have to be the domain name of the site. The site name will be used later and will refer to an entry in a table that supplies the hostname to the innxmit program that transmits the news articles by NNTP to the remote server. You may have multiple entries for each site; each entry will be treated individually. The pattern field specifies which news groups are to be sent to this site. The default is to send all groups, so if that is what you want, just make this field empty. This field is usually a comma-delimited list of pattern- matching expressions. The * character matches zero or more of any character, the . character has no special significance, the ! character (if used at the start of an expression) performs a logical NOT, and the @ character at the start of a newsgroup name means “Do not forward any articles that are posted or crossposted to this group.” The list is read and parsed from left to right, so you should ensure that you place the more specific rules first. The pattern: rec.crafts.brewing*,!rec.crafts.brewing.poison,@rec.crafts.brewing.private would send all of the rec.crafts.brewing news heirarchy except the rec.crafts.brewing.poison. It would not feed any articles that were either posted or crossposted to the rec.crafts.brewing.private newsgroup; these articles will be trapped and available only to those people who use this server. If you reversed the first two patterns, the first pattern would be overridden by the second and you would end up feeding articles for the rec.crafts.brewing.poison newsgroup. The same is true of the first and last patterns; you must always place the more specific patterns before any less specific patterns for them to take effect. flags controls and places constraints on the feed of news articles to this site. The flags field is a comma delimited list can contain any of the items from the following list, delimited by commands: