portal development


 
Thread Tools Search this Thread
Top Forums UNIX for Advanced & Expert Users portal development
# 1  
Old 05-30-2008
portal development

i am trying to develop a portal kind of thing where all the scripts will reside in unix.in our company we areusing Solaris.My requirement is to develop a portal which can be accessed from any where inside the oragnisation.If some one types a address 3.256.63.56/xxx.html the page should open.There should be many requests one user can put and for each request one button should be there.after pressing the button one shell script will run in unix and desired out put will be displayed.I have scripts developed in unix for all the stuff.only thing is to make it more interactive.i know a bit of html.how can i do this.the most imp thing is conncectivity between unix and the weblink.the restriction is i cant install any additional package in unix server.

please suggest me how to do this or some link where this can be found
Login or Register to Ask a Question

Previous Thread | Next Thread

1 More Discussions You Might Find Interesting

1. Programming

Need help in Ecommerce Portal Redirection?

Hi, I created one host ecommerce portal with complete ecommerce solution including payment gateway. To be clear I created ecommerce portal look like bigcommerce.com. I have already done with 98% backhand coding and also added a unique recognition number for each user after registration... (0 Replies)
Discussion started by: AimyThomas
0 Replies
Login or Register to Ask a Question
MOUNT_PORTAL(8) 					    BSD System Manager's Manual 					   MOUNT_PORTAL(8)

NAME
mount_portal -- mount the portal daemon SYNOPSIS
mount_portal [-o options] /etc/portal.conf mount_point DESCRIPTION
The mount_portal command attaches an instance of the portal daemon to the global filesystem namespace. The conventional mount point is /p. The directory specified by mount_point is converted to an absolute path before use. This command is normally executed by mount(8) at boot time. The options are as follows: -o Options are specified with a -o flag followed by a comma separated string of options. See the mount(8) man page for possible options and their meanings. The portal daemon provides an open service. Objects opened under the portal mount point are dynamically created by the portal daemon accord- ing to rules specified in the named configuration file. Using this mechanism allows descriptors such as sockets to be made available in the filesystem namespace. The portal daemon works by being passed the full pathname of the object being opened. The daemon creates an appropriate descriptor according to the rules in the configuration file, and then passes the descriptor back to the calling process as the result of the open system call. NAMESPACE
By convention, the portal daemon divides the namespace into sub-namespaces, each of which handles objects of a particular type. Currently, four sub-namespaces are implemented: tcp, fs, rfilter and wfilter. The tcp namespace takes a hostname and a port (slash sepa- rated) and creates an open TCP/IP connection. The fs namespace opens the named file, starting back at the root directory. This can be used to provide a controlled escape path from a chrooted environment. The rfilter and wfilter namespaces open a pipe to a process, typically a data-filter such as compression or decompression programs. The rfilter namespace opens a read-only pipe, while the wfilter namespace opens a write-only pipe. See the EXAMPLES section below for more exam- ples. CONFIGURATION FILE
The configuration file contains a list of rules. Each rule takes one line and consists of two or more whitespace separated fields. A hash (``#'') character causes the remainder of a line to be ignored. Blank lines are ignored. The first field is a pathname prefix to match against the requested pathname. If a match is found, the second field tells the daemon what type of object to create. Subsequent fields are passed to the creation function. The rfilter and wfilter namespaces have additional meanings for the remaining fields. The third field specifies a prefix that is to be stripped off of the passed name before passing it on to the pipe program. If the prefix does not match, no stripping is performed. The fourth argument specifies the program to use for the pipe. Any remaining fields are passed to the pipe program. If the string ``%s'' exists within these remaining fields, it will be replaced by the path after stripping is performed. If there is no field after the program name, ``%s'' will be assumed, to maintain similarity with the tcp and fs namespaces. FILES
/p/* EXAMPLES
A tutorial and several examples are provided in /usr/share/examples/mount_portal. The following is an example configuration file. # @(#)portal.conf 5.1 (Berkeley) 7/13/92 tcp/ tcp tcp/ fs/ file fs/ echo/ rfilter echo/ echo %s echo_nostrip/ rfilter nostrip echo %s echo_noslash rfilter echo_noslash echo %s gzcat/ rfilter gzcat/ gzcat %s gzip/ wfilter gzip/ gzip > %s gzip9/ wfilter gzip9/ gzip -9 > %s ftp/ rfilter ftp/ ftp -Vo - %s ftp:// rfilter nostrip ftp -Vo - %s http:// rfilter nostrip ftp -Vo - %s bzcat/ rfilter bzcat/ bzcat %s nroff/ rfilter nroff/ nroff -man %s As is true with many other filesystems, a weird sense of humor is handy. Notice that after the keynames, like nroff/ and bzcat/, we typically use another slash. In reality, the mount_portal process changes direc- tory to /, which makes the subsequent slash unnecessary. However, the extra slash provides a visual hint that we are not operating on an ordinary file. An alternative would be to change the configuration file to something like: nroff% rfilter nroff% nroff -man One might then use less /p/nroff%/usr/share/man/man8/mount_portal.8 SEE ALSO
mount(2), unmount(2), fstab(5), mount(8) HISTORY
The mount_portal utility first appeared in 4.4BSD. The rfilter and wfilter capabilities first appeared in NetBSD 1.5. The portal kernel driver was removed and mount_portal was converted to use puffs(3) in NetBSD 6.0. BUGS
This filesystem may not be NFS-exported. BSD
December 5, 2009 BSD