Linux Script

1 2 > >> (Page 1 of 2)
  • James E Lang

    James E Lang - 2004-08-25

    Is there anyplace in the documentation that describes the Linux script file -- how to install it, how to make use of it, in particular how to have it start or stop POPFile when a dial up connection is established or dropped respectively? If so, how do I find it?


    • Scott Leighton

      Scott Leighton - 2004-08-26

      No, there's not. One big issue is that the various distros all have different setups for init scripts. Add to that the fact that there's really no recommended or standard place to install POPFile (dir structure) and there are quite a few ways to have the mail configured under Linux, and the result is that documenting it all becomes a real challenge.


      • James E Lang

        James E Lang - 2004-08-26

        I understand what you are saying, Scott, but  John has written and supplied a script designed to be installed in subdirectory init.d for starting, stopping, restarting. or checking the status of POPFile. Additional subdirectories of which I am aware that *may* play a role include boot.d, rc0.d, rc1.d, rc2.d, rc3.d, rc4.d, rc5.d, rc6.d, and rcS.d. These subdirectories may not always be found in the same place in the directory tree but they seem to exist some place with most if not all of the distributions of which I've heard.

        *My* immediate concern is how to use that script in a dial up environment or modify it for such usage but the document should not be limited to that narrow functionality.

        The fact that there is such diversity in the Linux world does not remove the usefullness of well written generic documentation of this subject that is of a tutorial nature. Admittedly, experienced Linux users would probably not require this document but there are Linux newbies (like myself) who would benefit greatly from such a document.

        Among questions to be answered by such documentation are:

        1) How should one install the script for use with a fixed connection such as a DSL connection? This would include how to find the proper directories for this purpose and what tools, if any, normally exist for performing the installation of this script. It also would address the function played by the direcories that I referenced in the first paragraph above and in particular how to go about setting them up properly for use with POPFile.

        2) What adaptations are needed to the script for use with a dial up connection? This would include how to find an appropriate directory for this purpose, changes that would be needed to be made to the script itself stated in generic but tutorial terms, configuration of one's dialer software to make use of the start function of the script when a connection is established and to make use of the stop function of the script when a connection is lost. With the KDE desktop I know of the  dialer application kppp that I am told is fairly univerally available and the application kinternet that is available on my SuSE 9.1 distro. Both of these applications have the ability to supply a script to be run when a connection is established and to supply a script to be run when a connection is shut down. I have not been able to find, however, how to make this functionality work with John's script. As I understand things, user "root" (or generic equivalent) is required to run this script since the port number is less than 1k. The document needs to point this out and to tell how to accomplish this.

        As stated above, this document should be of a tutorial nature with special attention given to the Linux newbie. If my local Linux User Group gives me what I consider sufficient insight into this area (and I must say that they are trying to), I'd be glad to write such documentation but at present I do not feel at all knowlegeable to do so.


        • Scott Leighton

          Scott Leighton - 2004-08-27

          >I'd be glad to write such documentation but at present I do not feel at all knowlegeable to do so.

          I'm in the same position as you, I can probably describe my own setup, but I don't know enough to intelligently advise others on their setups. Too many differences and too many gaps in my knowledge.


          • Texas Fett

            Texas Fett - 2004-08-27

            We could probably come up with some general guidelines, but since none of us are Linux experts and distros vary widely in this area we probably shouldn't get too specific.  There are enough of us that are at least part time Linux users or recent converts that together could work something out.  Since each of us probably uses a different distro we should be able to at least give general ideas of what needs to be done.  It will have to be up to the user to figure out exactly how.

            If we can sort of cover RedHat/Fedora, Debian, and Suse that probably covers most distros new users will be on.  I can add Gentoo since thats what I use, if I can figure out what I did.

            Figuring out how to setup starting PF when you dialup is probably way over our heads.  I don't doubt there is some way to do it, but it may require an extra utillity or something.

            But at this point its not a high priority for me.  We are going to need to finish updating the Wiki for 0.22.  I think we have most of it already, but who knows.  And I still want to figure out how to reorganize the main page and FAQ.  That is not easy.  And it doesn't help that I can't ever seem to work on it.

            • Scott Leighton

              Scott Leighton - 2004-08-27

              >And it doesn't help that I can't ever seem to work on it.

              I know what you mean <g>. When I get a chance,  I'll take a stab at documenting a 'standard' SuSE setup where are all users are sharing one install of POPFile and are retrieving mail via fetchmail. Basically, that would simply be documenting my own setup which I know works, and works well.

                I guess if enough users pitch in, eventually we'll cover all the major setups.


              • Texas Fett

                Texas Fett - 2004-08-27

                I haven't even got that complex.  All I know how to do is get it to start automatically.  With help from John's script it wasn't hard, but to begin with I had no idea where to put the script or how to get it to run.  So far I only use it for testing so I haven't worried about fetchmail.

                Suse is probably the current most popular so its good that you can get that one covered.  I think Debian is not too different from Suse.  But RedHat and Gentoo are different from everyone else in some major places.

                • James E Lang

                  James E Lang - 2004-08-29

                  "Suse is probably the current most popular so its good that you can get that one covered. I think Debian is not too different from Suse. But RedHat and Gentoo are different from everyone else in some major places."

                  OTOH, SuSE uses the Red Hat Package format for intalling packages.


              • James E Lang

                James E Lang - 2004-08-27

                ">And it doesn't help that I can't ever seem to work on it.

                I know what you mean <g>."

                I'm sorry, guys, I know you are both "up to your armpits in alligators" at present. I was hoping to reach some other good souls with my plea for help on this one.

                "When I get a chance, I'll take a stab at documenting a 'standard' SuSE setup where are all users are sharing one install of POPFile and are retrieving mail via fetchmail."

                Ok, that would be above and beyond what I was initially requesting but good to have as well. My request did not go into the area of  configuring the client software complex to use POPFile but rather concentrated on the mechanisms used to start POPFile running and shutting it down. For fixed connections this could be a one time thing as a part of starting the system (or maybe the user logging on) and rebooting (I know, "who cares," but maybe it's the user logging off instead -- I really don't know which is appropriate). For dial-up connections it needs to be tied in to the dialer application. At my local LUG (Linux User Group) I am told that most dialers have the functionality to run a specified script after connection and to run another specified script after disconnection. When I get this to work for me, I'll add my miniscule bit of knowledge to the reservoir and all the boats will hopefully float a little higher.

                "Basically, that would simply be documenting my own setup which I know works, and works well."

                My own configuration involves running POPFile with my old Windows mail client (Pegasus Mail) running under Wine. Once I get POPFile running (nothing automatic) the POPFile portion of this works just fine. I have used two different scripts with success for manually starting POPFile (John's and a quick and dirty one that David had created for me when he first set me up on the Linux system). To shut POPFile down I need to either use John's script manually or access the UI and tell it to shut down POPFile. The status function of John's script is far from foolproof. It mearly tests if the pid file exists. This can be true if POPFile has died as well as if it is running. Trying to use the UI is far more trustworthy in my experience.

                Accessing the UI from the Linux version of the Opera browser works just fine. I have run into no anomalies here.

                "I guess if enough users pitch in, eventually we'll cover all the major setups."

                Yes, a team effort will certainly be called for. One thing I'll have to add to my knowledge in order to participate is how to contribute to a wiki but I know that there is help in that area already in the documentation area.

                Thanks for taking my issue seriously and again I wish there were people who are not already so tied up in getting out the POPFile code who could address themselves to this issue. I am posting a message on the general discussion forum ("Call for Linux Documentation Help") asking for documentation assistance from Linux users of POPFile and referring them to this thread. I don't think I stepping out of line to do this -- I certainly hope not! My wrist is extended for John to slap it if he thinks that I am out of line.


    • Lucas Wall

      Lucas Wall - 2004-08-28


      I've just ran into this thread and I think I can help. I don't have a lot of time currently, but I'll be glad to share my experiences with popfile if someone find it useful and reformats them into something useful for the wiki or docs.

      I'm the maintainer of the Debian popfile package:

      I can really only talk about Debian, and maybe some general linux setup, but I've heard people have packaged popfile for other distros. If someone can track them down and mail them I'm sure they will be glad to help.

      Now about the question that started this thread...

      As jelang pointed out the init script should go in init.d. The script john made is for a sysv init scheme (the one with rc1.d, rc2.d, etc). As far as I know most distros use sysv scripts. Slackware is an exception, unless it changed, I haven't installed slack in a coupple of years.

      Once you put the init script in init.d you should create symbolic links to it in the diferent rc?.d dirs. Depending on the dir number... either Snnpopfile or Knnpopfile. Where nn a number. Mmmm... All this sounds a bit confusing... I'll start from the begining.

      After the system boots it needs to bring up all the diferente services (daemons, etc). The first process the kernel runs is init (always process with id 1). Init then reads its config /etc/inittab and, depending on the runlevel, runs a specific script.

      The runlevel is just a number 0-6 that tell init what it should bring up and down. 0 is always halt and 6 is always reboot. These two actualy run when you shutdown your linux. Runlevel 1 is usually single user mode (for maintainance). Runlevels 2 to 5 are multiuser modes and the sys admin decides what to bring up and down on those. The default runlevel (the one you get when you just turn on your linux) is usually 2.

      On sysv schemes the script that init runs scans one of the rc?.d dirs, the number is the runlevel. It grabs all the files that start with K and runs then with "stop" as param. Then grabs all the files that start with S and runs them with "start". All those files have numbers after the S and K to make them run in a specific order. (Some services must be started before/after others).

      So... for example... On my system the init script is in /etc/init.d and I have the following symlinks to it:


      This maked popfile start in runlevels 2 to 5 and stop it in runlevels 0, 1 and 6. So... Popfile starts when I boot (runlevel 2) and stop when I halt (0) or reboot (6) my machine. It also stops if I change to runlevel 1 to fix something.

      Ok... I've babbled enough about the init script.

      The point is that with a sysv scheme you will always have an init script that accepts start and stop. Diferent distros might have diferent init scripts (I made one for Debian), but they all accept start and stop. And, as far as I know, they are always in /etc/init.d.

      So you can use that script in other places other than rc?.d dirs. In particular you can make pppd run it when it brings an interface up or down.

      From pppd man page (at least in Debian):

                    A program or script which is executed when the link is available
                    for  sending  and  receiving  IP packets (that is, IPCP has come
                    up).  It is executed with the parameters

                    interface-name  tty-device  speed  local-IP-address   remote-IP-
                    address ipparam

                    A program or script which is executed when the link is no longer
                    available for sending and receiving IP packets.  This script can
                    be  used  for  undoing the effects of the /etc/ppp/ip-up script.
                    It is invoked in the same manner and with the same parameters as
                    the ip-up script.

      You just have to add (or create the script, if you don't have one, with) a call to popfile's init script with start in ip-up and stop in ip-down. Actually in Debian you have to add a script in a directory called /etc/ppp/ip-{up,down}.d, but I don't know if other distros use the something.d scheme as much as Debian does.

      • Texas Fett

        Texas Fett - 2004-08-28

        Hi Lucas.

        Thanks, that should help us tons.  I doubt we could have come up with that good a description of what is going on on our own.  One of us will definatly get it into the wiki as a starting point for a Linux install guide.  You have provided us with stuff that should also be a good help in getting us started on some other distros.  And contacting the other package maintainers is a really good idea since obviously they know more than we do.  I do know several other distros have PF packages.

        I have a couple questions.  Where is a good place to install POPFile if your setting it up for multiple users?  And is there anything else special we need to do for multiple users?  So far all I have ever attempted was a single user setup with the user data directory the same as POPFile root.  Debian specific answers are fine, if you have any general advice thats great too.

        Thanks a lot for helping us out and for maintaining the Debian package.

        • Lucas Wall

          Lucas Wall - 2004-08-28

          Were to install is really distro dependant, but generally, when the author provides a script that does instalation on linux, one expects it to go somewhere under /usr/local. At least GNU software does that.

          Usually when someone gets a program and makes a package he tweaks the install script to place then on dirs out of /usr/local.

          So, as a soft rule, the sys admin knows that the stuff he installed manualy is in /usr/local and outside that files are handled by the packaging system.

          Debian has a very strict policy about were files should go. Debian's popfile package splits popfile into the following dirs:

          /usr/share/popfile - all the scripts
          /var/lib/popfile - everything popfile writes and changes
          /usr/share/doc/popfile - the web documentation

          You could probably use:

          /usr/local/share/popfile - all the scripts and web docs
          /usr/local/lib/popfile - the user data

          About multiuser support... The current multiuser support is not really enough for linux. In general popfile has some problems on linux. A newbie might scratch his head for hours wondering why popfile spits an error with port 110 (even when he starts it as root) and not know that he has a pop3 daemon running because he answeres yes to a question when he installed his linux. Popfile dosen't either behave as a "good" daemon. It dosen't fork to background, detach from the terminal, chdir to /, etc. So the init script has to do all this. All this points can be easy to solve by someone with some experience, but a newbie can be easily burned out.

          If you really want to provide some kind of multiuser support with the current version you have two ways of doing it.

          One is by running several instances of popfile with diferent ports. No very useful if you want to handle several users, but... Its still a posible way to set it up.

          You can install popfile in /usr/local/share/popfile and make each instance write its data to subdirs under /usr/local, or similar, eg: /usr/local/lib/popfile/user1, /usr/local/lib/popfile/user2, etc.

          You use the init scripts and rc?.d links to bring popfile up, or the if-{up,down} scripts.

          The other way I can think of would be more like the windows way to run a multiuser popfile instalation. You install popfile under /usr/local/share/popfile and then provide scripts similar to this:

          --- /usr/local/bin/start_popfile ---
          set -e
          if [ ! -d $HOME/.popfile ]
              mkdir $HOME/.popfile
              cp /usr/local/share/popfile/stopwords $HOME/.popfile/
          cd $HOME/.popfile
          export POPFILE_ROOT=/usr/local/share/popfile
          export POPFILE_USER=$HOME/.popfile
          umask 0077
          exec /usr/local/share/popfile/ \     --set config_piddir=$HOME/.popfile/ \     --set html_port=7070 \     --set pop3_port=7071 >/dev/null 2>&1 &

          --- /usr/local/bin/stop_popfile ---
          kill `cat $HOME/.popfile/` >/dev/null 2>&1

          (Note that I haven't done a lot of testing with these two scripts, just wrote then now and ran them a coupple of times)

          Now... Each user is responsable of starting and stopping popfile with these scripts. Two users can't run popfile at the same time, but this kind of setup would be for a desktop machine that is used by one user at a time.

          Popfile would run as the user and save everything in their home, which makes perfect sense under linux. With this scheme you can't run popfile with ports < 1024, but as I said before that's not a good idea anyway. Even when started with the init script during boot I don't run popfile with root, I make it run with a popfile user. Its more secure...

          Unfortunately there is no good place to put a call on start when the user logs in and stop when he logs out. Probably the best place would be when X starts and stops, but... If you want to make it work for all users in general you have to hack into really specific distro scripts and if you want to tell users how to set it up with more simple scripts in their home dirs you have to explain how X scripts use diferent files in their home dir to load the server/client. With the last option you have to also make them write a whole bunch of instalation dependant stuff that the general X scripts do, but you have to repeat to be able to override them.

          Ok... Enough for now, its late and I have to go to bed. :-)

          • Texas Fett

            Texas Fett - 2004-08-28

            I should be in bed too.  But I though I would reply now anyway since I am up.

            The Windows like way you described for multiuser is probably what I was thinking of.  I know true multiuser isn't possible yet.  I am sure you know we have plans for it in the somewhat near future (not 0.22).  By that time maybe we can improve some of the other Linux stuff you mentioned.

            • Lucas Wall

              Lucas Wall - 2004-08-28

              I know the true multiuser support is planed for the future. I'm waiting for that to be able to deploy popfile on a coupple of servers at work. As far as the improvements I mentioned, those would be nice but not critical. You can always wrap popfile in a script.

              It would be nice if popfile could integrate into the MTA (sendmail, exim, etc). Usualy that is donde by providing a straight filter script using pipes. I once tried the pipe script that comes with popfile, but it felt more like a testing script...

              Going back to the documentation issue and sample install scenario... Maybe we could try to get popfile working in your linux system with the current multi user support. Then you can document the steps involved.

              You mentioned that you wanted popfile to go up while the ppp link it up. You also mentioned kppp, so I asume you use KDE. Do you log in with kdm, or by running startx?

              The goal of this particular instalation would be to have popfile go up when you bring your link up, but running as the user that brought the link up. Also popfile would be installed by root, and each user would have his own data file in their home.

              I think thats complex enought to cover simpler cases. What do you think of this?

              • Texas Fett

                Texas Fett - 2004-08-28

                I think is kind of in between.  It can be used as a testing script or for filter.  The only limitation is that it doesn't add messages to the history.  That possibly could be an option now that we have that capability added for XMLRPC.  Another thing for after 0.22 probably though.

                • Lucas Wall

                  Lucas Wall - 2004-08-29

                  Yes... The fact that it didn't add messages to the history made me turn it down as an alternative to the pop3 proxy. After that I didn't invetigate any further, and that was a long time ago.

          • James E Lang

            James E Lang - 2004-08-29

            Lucas, I greatly appreciate your contribution to this discussion.

            I'm so green when it comes to Linux that when I read Lucas' first message I wondered how to create a symlink. I looked for Linux style documentation which is great if you know for what you are looking but then, often you don't need the documentation ('twould be nice if there were an index to Linux documentation on the system which could be displayed by simply typing "help"). I tried "man sl" which does not exist. I tried "man syl" which also failed. Then I tried "man syml" still with no success. Finally I got desperate and tried "man symlink" which I figured stood no chance of success only to find that it appears to be correct. My point here is that even though things may be "simple" or "basic" in the eyes of Linux experts, they are nothing like that in the eyes of the newbie who is just entering the Linux world after years of experience in a very different Windows environment. There is no need to be verbose in describing what to do but an example that shows what to do is appropriate. A simple one line example would be worth a whole lot of words in getting the newbie headed in the right direction.

            As for the post to which I'm now responding, I have a question. In the Start_popfile script there is reference made to ports 7070 and 7071. To what do they relate? Are ports 110 and 143 still used in interfacing with the POP3 and IMAP servers? If so, how does the need to operate as "root" when starting POPFile eliminated?

            FWIW, I've been using my browser to shut POPFile down. I have created a bookmark for http://localhost:8080/shutdown for this purpose. The biggest problem with this, IMO, is that it is not automatic but it does not rely on the existence of a file that POPFile creates during start up and that it removes when it shuts down *cleanly*. This distinction may be a non issue -- I just don't know.

            My distro is, once again, SuSE 9.1. Using YaST ("Yet another Setup Tool" which is a part of the SuSE package) to configure my modem and dial out connection, I can either configure my dial out port for "dial on demand" or for manual connection. If I use "dial on demand" the transmission that triggers the connection seems to get lost so I've been using the manual connection mode but I *have* tried both ways of connecting.

            I don't know whether or not ppp0 is involved in the process of establishing my connectons so I don't know about the usage of scripts as Lucas is recommending. I do know that my local Linux User Group recommends that I use similar functionality. Since my desktop is run by KDE 3.2, they have suggested that I use kppp but I don't find it anyplace on my system.  On my computer, there is an icon in the system tray for which the tool tip is "Kinternet - Internet tool." Right clicking the system tray icon for Kinernet gives me a menu which includes "Settings" and from the menu it displays I can select "Various settings..." which displays a box with tabs. One of those tabs reads "Scripts." Selecting the scripts tab I find a place to enter the location of a script to be used after connection and a place to enter the location of a script to be used after disconnection. Specifying John's script with a start or stop parameter (as the case may be) did not work. I don't know about Lucas' two scripts. I'm going to be trying them on the theory that the reason I can't get John's script to work in this case is that parameters are not allowed in these fields. Lucas' scripts don't require parameters.

            I've spent the past hour or more composing this post so I hope that I am not replowing a field that has already been satisfactorily plowed by other messages in the interim.


            • Lucas Wall

              Lucas Wall - 2004-08-29

              Well... Yes... I do undestand some of my coments might not be completly evident for someone completly new to linux. Thats why someone should chew this thread, and probably others, to make something useful in the wiki (or somewhere else). A good instalation guide for newbies should include step by step commands intermixed with explanations.

              Its true that linux lacks a standard central doc index. Man is not really the place to look if you don't know what you are looking for. Man pages are usually reference pages to commands or other general parts of the system. BTW... With man you can do "man -k <word>" to look for something. "man -k" is actually apropos, so do "man apropos" to get more info on man searches.

              Some programs, mostly GNU, also provide manuals as info pages. You can run "info" to get into the general index.

              Finally... A good place to get general info for linux is:


              There you can find all sorts of HOWTOs and guides. But beware that most of them might be too generic and not work straight forward on your system, specially if you use frontends to configure it.

              I'm sure you will find one, or several, intros to linux in TLDP site. One that explains all the basics: symlinks, etc.

              Ports 7070 and 7071 overide the default ports for the pop3 proxy and web interface. The script I posted can't run as root, so you can't use ports <1024. I didn't include the imap port option, you should add it, mapping it to another port, if you use it.

              The reason the script can't be run as root is that it uses the variable $HOME to determine the home directory of the user that runs the start script. The idea is that diferent users can start/stop popfile and get separate data dirs.

              Using the shutdown link or the script is similar. If you run the script and popfile is not running it will fail, but thats ok, popfile is not running anyway. With the simple one line stop script you could argue that a stale pid file might try to kill something thats not popfile, but thats a remote posibility, and more remote if you are not running it as root. Further, the stop script could be a bit more complex and check that the pid (process id) really corresponds to a running popfile instance.

              The scripts I talked about (ip-{up,down}) are part of the ppp program. Behind the scene your setup tool is using them, but you don't need to dirctly fiddle with them if you have configuration options in your system. I can't talk about specific setup tools I don't use, but the options you mention sound like those scripts.

              But... Be careful of just pluging my scripts into those options. The ppp program must run as root to establish the conection and will usually run those scripts as root. Any wrapper you use around ppp (kppp,
              etc) will eventualy run ppp as root automaticaly. You will have to test it and see what happens.

              If the script works, but runs as root you will find that the ".popfile" dir is not on your home. Instead you will find it in "/root/.popfile" ... or you might find that the ".popfile" dir is in your home, but the files are owned by root instead of your user. To know if popfile is running as root you can also do a "ps aux" and look for the popfile process in the list.

              If the script runs as root you can replace the $HOME var with a fixed path. You can also remove the options and make popfile listen on low ports.

              But... I said in my last post, but I repeat it again. Usually its not a good idea to run daemons as root if you can avoid it. One reason is security... If a serious security bug slips into popfile and popfile runs as root someone could exploit popfile to get a root shell. If popfile runs as a normal user they will only have limited access to your system. Another reason is damage control... If a grave trashing bug gets into popfile and the program berseks it won't be able to trash your system if its not running as root. Anyway... this last paragraph is, of course, a matter of personal taste. There are situations in which you will need, or just want, to run popfile as root and accept the risks.

              • James E Lang

                James E Lang - 2004-08-29

                Lucas, I did not mean that you needed to answer all the questions though I certainly appreciate your responses.

                "Ports 7070 and 7071 overide the default ports for the pop3 proxy and web interface. The script I posted can't run as root, so you can't use ports <1024. I didn't include the imap port option, you should add it, mapping it to another port, if you use it."

                So are those port numbers chosen arbitrarily or are they standard alternate ports?

                Will my ISP know what I'm doing if I use port 7070 in place of port 110? Or have I totally missed your point?

                Does port 7071 replace port 8080? If so, why? Port 8080 is already >1k. Obviously I'm misunderstanding something here and I hope I'm not the most uninformed person who will use the documentation that I have been requesting.

                After clarification of these issues, I'll look into the IMAP port substitution.

                I hope everyone else that is reading or otherwise participating in this thread also understands my point of view. I've been told that with my level of understanding, my greatest contribution to this effort may be that of a reviewer from the point of view of a newbie. I hope, rather, that I can gain knowledge from a variety of sources and contribute more directly to the effort while still being close enough in time to the very green newbie state that I'll recognize items that remain uncovered.


                • Texas Fett

                  Texas Fett - 2004-08-29

                  Choosing the ports 7070 and 7071 is kind of in between arbitrarily and standard alternate ports.  It is common to choose a similar number for a port that offers the same or similar service.  Its done for convienance because its easier to remember if there is some reasoning to the port number.

                  Port 80 is the normal HTTP port, so that is why POPFile uses 8080 for its HTTP (UI) port.  But 8080 is a somewhat common port for many similar programs.  So for a bit of security by obscurity and to avoid possible conflicts with other programs choosing a less common number may be desirable.

                  The choice of 7070 is likely because its similar to POPFile's default 8080.  And setting POP as 7071 is for convienance, you don't have to remember where the other ports are if they are all sequential.  So IMAP could be 7072.

                  Being a newbie in Linux definatly gives you different way of looking at things.  But your not really that far behind the rest of us in Linux, compared to Lucas we are all newbies.

                  • Lucas Wall

                    Lucas Wall - 2004-08-30

                    Yes... 100% right. The port choice is completly arbitray, but follows some kind of unwritten/general convention. The fact that texasfett described exactly what I thought when I chose those ports proves it. :-)

                    Except probably for the part of "security by obscurity". Its all about avoiding colission with other programs and easy to remember.

                    But remember I was choosing the new default ports that the Debian instalation would use. So I had to think, and look for, ports that would not collide with other common Debian packages. In a manual instalation you are completly free, once you stop using the standard 110/143 ports it makes no real diferences what other ports you use.

    • Scott Leighton

      Scott Leighton - 2004-08-29

      OK, I've taken a stab at SuSE here...


      • James E Lang

        James E Lang - 2004-08-30

        Thank you Scott. I'll have to give it a try and see where I trip up. One thing I notice immediately is that it does not address the dial out environment. Of course, John's script is not designed for that.


        • Scott Leighton

          Scott Leighton - 2004-08-30

          No, for dialup environments, you'd use the advice that Lucas Wall gave you.

          Do not install the init.d service (the insserv /etc/init.d/popfile). Instead, install simple wrapper scripts;

          in /etc/ppp/ip-up.d/

          rcpopfile start

          in /etc/ppp/ip-down.d

          rcpopfile stop

          That should start/stop POPFile when you bring up or down the the dialup connection.

          An alternative method would be to install a setup to your $HOME directory as Lucas suggests (running non-root) and then use KDE's autostart and shutdown capability to start it up and shut it down for your KDE session (more complicated though, and I've never tested).


          • James E Lang

            James E Lang - 2004-08-30

            Ok, Scott. For the moment I have one more "suggestion" for your document and that is to add instructions as to how to uninstall after having installed as you suggest.

            No, I have not performed the actual install as you described it though I have converted all but the actual creation of the wrapper scripts and John's script into a single Install_POPFile script. I would still like to test my script but not without an uninstall procedure.

            As for the dial out scenario, you suggested that I use Lucas' scripts but then suggested some of your own. Aren't the two in conflict with each other? If I use Lucas' scripts don't I have to configure things differently in my mail client to use ports 7070, 7071, and one for IMAP (possibly 7072)?

            BTW, I notice that directory linux from the CVS is not a part of the cross platform zip file (at least its not in I think this is a mistake but I guess this is the wrong forum on which to mention that..


1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.

No, thanks