#foswiki 2017-08-23,Wed

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)

WhoWhatWhen
***ChanServ sets mode: +o Lynnwood__ [00:50]
....... (idle for 33mn)
GithubBot[distro] gac410 pushed 1 new commit to Release02x01: https://git.io/v5kN4
distro/Release02x01 ff12fc1 George Clark: Item14462: Make AuthScripts visible in configure...
[01:23]
***GithubBot has left [01:23]
FoswikiBothttps://foswiki.org/Tasks/Item14462 [ Item14462: {AuthScripts} is hidden unless Template Login is in use. ] [01:23]
GithubBot[distro] gac410 pushed 1 new commit to master: https://git.io/v5kNR
distro/master 2d1a826 George Clark: Item14462: Make AuthScripts visible in configure...
[01:24]
***GithubBot has left [01:24]
.... (idle for 18mn)
GithubBot[SmsTwoStepAuthContrib] gac410 pushed 1 new commit to master: https://git.io/v5kA2
SmsTwoStepAuthContrib/master 48503b0 George Clark: Item14459: Documentation and configure fixes...
[01:42]
***GithubBot has left [01:42]
FoswikiBothttps://foswiki.org/Tasks/Item14459 [ Item14459: Port SmsTwoStepAuthContrib to Foswiki ] [01:42]
................. (idle for 1h23mn)
GithubBot[SmsTwoStepAuthContrib] gac410 pushed 1 new commit to master: https://git.io/v5kjs
SmsTwoStepAuthContrib/master 55f854e George Clark: Item14459: Insert comma in carrier options list...
[03:05]
***GithubBot has left [03:05]
FoswikiBothttps://foswiki.org/Tasks/Item14459 [ Item14459: Port SmsTwoStepAuthContrib to Foswiki ] [03:05]
.......................................................................... (idle for 6h9mn)
***ChanServ sets mode: +o MichaelDaum [09:14]
...................................... (idle for 3h5mn)
ChanServ sets mode: +o gac410 [12:19]
............ (idle for 59mn)
ChanServ sets mode: +o Lynnwood [13:18]
........... (idle for 52mn)
zak256Is there a way to trigger bootstrap after unpacking the Foswiki archive and restoring LocalConfig.cfg from a backup without accessing the webpage?
Or there is something else wrong... The website tells me "WARNING LocalSite.cfg could not be found", but I copied it to the lib directory. Permissions are okay, too.
[14:10]
gac410If LocalSite.cfg exists and is valid, it should not need a bootstrap. Is the bootstrap message on your Main/WebHome, or only when you access bin/configure [14:13]
JulianLevensYour irc references the wrong name LocalConfig.cfg is it that simple? [14:14]
gac410good point ') [14:15]
zak256Hmm... I see... the message says LocalSite.cfg, that is the correct name then I think.
Yeah, that was it. Stupid error... Thanks.
By the way, I couldn't find out if I need to replace the file mod_perl_startup.pl
There is http://foswiki.org/Support/ModPerlStartup which tells me to generate the file and place it in the tools directory.
But there already is a file with that name.
Is the webpage obsolete? Or is the existent file just a placeholder?
[14:18]
gac410Obsolete I think When we bundled mod perl with foswiki, we supplied some of that stuff [14:23]
zak256okay, great. Less work to do afterwards. [14:23]
gac410There may be some stuff in that version that is better than the bundled version ... I've never really compared them.
To really do it right, I believe mod_perl needs some tuning. I mainly use Fastcgi, so I'm not really familiar with it.
[14:24]
zak256I really don't know... is Fastcgi better than mod_perl? Should I use Fastcgi? [14:26]
gac410They each have their advantages. FastCGI can avoid webserver restarts, especially if you are hosting multiple vhosts. [14:27]
zak256We don't. [14:28]
gac410mod_perl loads all of the code into apache, so the only way to refresh is to restart the server. [14:28]
zak256I guess that is not that much of a problem for us, because the code doesn't change so often and restarts are no serious problem. [14:29]
gac410FastCGI also can have limits so that the handlers restart after some number of requests. That can help keep memory use in control
We try to stomp out memory leaks but they do happen.
[14:30]
zak256A switch from mod_perl to FastCGI (and back) should be possible without too much problems, is that correct?
So I can consider this at some later point again.
[14:33]
gac410y, foswiki should not care at all. It's all part of your apache configuration.
under the covers, mod_perl is a window into apache internals. Foswiki *could* make deep internal access to the Apache internals and API. But we don't. From our perspective, it's purely a way to precompile / load foswiki
[14:34]
zak256okay
The fix_file_permissions.sh gives me errors about two files: find: ‘working/configure’: No such file or directory and chmod: cannot access ‘data/.htpasswd’: No such file or directory
I guess they will be created later during use?
[14:36]
gac410hm If its a new install they might not exist. But if you have any registered users, data/.htpasswd really should be there.
Unless you are using some other password manager than out default
.htpasswd is where we store the user's registered email address
[14:38]
zak256yes, we use AD
but alright, then it's no real error.
[14:39]
gac410Ah.. okay. So probably not used. [14:39]
...... (idle for 29mn)
zak256Is it possible to provide additional binaries which do not belong to foswiki in a separate bin-dir without the need to have two bin-dirs for the web access? [15:08]
......... (idle for 40mn)
gac410zak256: What type of binaries... Are you extending foswiki or something unrelated?
by the way, when you are using mod_perl, the bin directory isn't really used iirc
[15:48]
zak256Those who are usually located in Foswiki/bin/, like view, viewauth, etc
Really? What is used for view then?
(for example)
[15:49]
gac410The bin scripts are mostly used only with plain CGI. With fastcgi, only foswiki.fcgi is used. With mod_perl, I believe that the mod_perl engine invokes the UI's directly.
The bin scripts don't do much. They only load foswiki, and then transfer control to the engine. The meat of foswiki actions are in lib/Foswiki/UI/....
[15:50]
zak256so I can totally leave out the bin-scripts from the archive and only put our scripts there? [15:51]
gac410hm I'm not sure if their presence is used to detect valid Foswiki actions. I've never tried leaving them out. [15:52]
zak256I will just try. [15:52]
gac410But as far as the web server transferring control to foswiki, the bin scripts are mostly for plain old CGI. [15:52]
zak256My intention is to separate all original Foswiki-data from working data and additional data from us
So we know what belongs to what and upgrades should be easier (I hope)
[15:52]
gac410That's really hard to do Some things have to live in System. etc. [15:53]
zak256Yes, I created a new folder data and copied the files from the archive there.
so all our changes will be done in the new folder and the original one is kept for reference
[15:54]
gac410If you really want to separate your stuff, it's possible to rename some webs. ie Main could be UsersWeb, Sandbox could be Playground, etc.
But System. No good solutions. Plugins / extensions install there. Not much to do about that.
[15:55]
zak256Is "Main" really only used for the users?
I was thinking about creating a new UsersWeb only for users (and groups?)
[15:55]
gac410Well it also has your SitePreferences and customized UserForm, UserRegistration pages, etc. [15:56]
zak256Exactly... [15:56]
gac410Our upgrade packages only ship a very small number of Main topics, if any at all.
I rename Main, Sandbox here on my development system, So I have a "pristine" Main directory, checked out from github.
[15:56]
zak256I don't want to use upgrade packages. Normally we place the full archive on a special server and write an elaborate install script which does all the installation and configuring stuff.
But I will think about it.
[15:57]
gac410There is a upgrade script as well, but not widely published. http://foswiki.org/Support/HowDoIUpgradeSafelyACustomizedFoswikiInstallation
We use a modified version of it for upgrading foswiki.org.
[15:59]
zak256The first thing is still creating a completely new version and migrating the existing data from the old 1.1.2 installation. [15:59]
gac410Ah. 1.1.2 Y, you have some work. BTW best to use CharsetConverterContrib, and not the bulk_copy too,.
tool
[16:00]
zak256yes... I know... :-( [16:00]
gac410If you are not modifying Foswiki "shipped" topics, then the upgrade package should work well. If you are modifying the skin, system topics or other stuff we ship, then the script I referenced can be handy
In most cases though there are ways to tailor foswiki without resorting to modifying our distributed files.
[16:02]
zak256yes, but this has to be integrated in our installation routine as well, handling big problems where for example the complete server has to be setup again
so I could either add commands to patch the installation afterwards or just replace the Foswiki-abc.tar with the newer one
[16:04]
gac410You can't just restore a backup of the foswiki installation?
If you really want to set up from scratch, Foswiki 2.x does have a scriptable configure. you can use tools/configure with commands to bootstrap and fully tailor a new install.
[16:06]
zak256Well, we have backup of data of course... [16:07]
gac410Probably easiest to treat the whole foswiki installation as your data. [16:08]
zak256I know of the scriptable configure, but I think keeping LocalSite.cfg on the server is a better solution for now [16:09]
gac410y. Scriptable configure is probably more useful for automated deployment of a new foswiki site, not for backup/restore purposes.
You really need to treat the System directory as user data, since every extension you install goes there. And extension are pretty tightly tied to their modules in lib directory. So that has to go as user data too.
[16:09]
zak256The nice thing about the install-script is, that everything is defined there. If changes are done later on the real machine which are not really documented, the install-script can create a system again in the defined state.
But I think about setting the configuration parameters by script again.
What do you mean with "System directory" ?
[16:11]
gac410parameters are one thing. But all the extensions are another challenge. Yes you could automate that too, but you'd be getting the latest version, not the one you are currently using.
sorry data/System and pub/System
[16:12]
zak256Versions are a good point. I need to put the exact version we test and deploy on the install-server.
If at a later time, the server is setup again, there _must_not_ be a newer version, without further testing and approval.
[16:13]
gac410We really don't have any mechanism to "version" extensions. The installer always gets the latest from us. Unless you download and locally store the tgz and _installer files. [16:13]
zak256exactly, that's what I have to do [16:14]
gac410tbh. a full backup of the foswiki directory is really the cleanest. [16:14]
zak256Nothing is downloaded from the web during install [16:14]
gac410anyway, I have to get back to some stuff here. I'll check back off and on. [16:14]
zak256Okay. Thanks for the input. I seriously appreciate it! [16:15]
...... (idle for 27mn)
***zak256 has left [16:42]

↑back Search ←Prev date Next date→ Show only urls(Click on time to select a line by its url)