Re: [wpkg-users] [Bug 175] Test return value of removeSettingsNode function
Starting from the beginning again :)
I adminster several small school networks and use wpkg to deploy packages to
several machines if it is quicker to use wpkg than to go around all
computers and do a manual install.
I want to be able to test a new package out or a modified one on an existing
live system.
I do this by trying to allocate/modify a package on one computer.
In practice, I have found this difficult to achieve this cleanly without
breaking something sometimes :(
Currently, WPKG will remove a package entry from WPKG.xml if it decides that
the package is no longer required for that computer.
Even with the two exisiting flags (noremove and noforced remove) WPKG will
still remove the package entry from WPKG.xml under certain circumstances.
If a mistake is made, and then later rectified, then WPKG thinks it hasn't
installed a package and attempts re-install.
IF I programmed a package with checks - I could probably work around this
but I don't. I don't use checks and I dont use remove commands. I just have
an install command to install and an update command to update -very simple
:)
If I could have a flag to stop WPKG from removing package entries, then when
my mistake is rectified, wpkg would not attempt a re-install.
Its that simple :)
I don't use WPKG to keep track of everything on my network - I just use it
if it might save me time and effort.
Obviously if I had a separate testing setup, virtual/real testing machines
or didn't make mistooks then I wouldn't have a problem - but I dont have
these and therefore I have a problem :)
regards
Simon
PS
Just for reference my basic code change proposal is
function removeSettingsNodeSW(packageNode, saveImmediately) {
// sw modified to stop removal if no remove instructions found
if (getPackageCmdRemove(packageNode).length 0) {
// make sure the settigngs node is selected
var packageID = getPackageID(packageNode);
dinfo(Removing package id ' + packageID + ' from settings.);
var settingsNode = getSettingNode(packageID);
var success = false;
if(settingsNode != null) {
success = removeNode(getSettings(), settingsNode);
}
// save settings if remove was successful
if (success saveImmediately) {
saveSettings();
}
return success;
} else {
var packageID = getPackageID(packageNode);
dinfo(package id ' + packageID + ' not removed as no remove
instructions found.);
var success = false;
return success;
}
}
and then the calling code should check the return success value
I also use WPKG across 16 schools. One of the first things I did when
trialling and now using wpkg live was dredge out an old and unused PC capable
of running XP Pro and set this up as a test workstation for wpkg packages
before I roll things out to the live networks.
If you don't ever want wpkg to remove an entry from the local wpkg.xml file
then just leave the entry in the profile.xml.
_
View your other email accounts from your Hotmail inbox. Add them now.
http://clk.atdmt.com/UKM/go/167688463/direct/01/-
wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/
___
wpkg-users mailing list
wpkg-users@lists.wpkg.org
http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 176] WPKG Service crashes when using Offline mode
http://bugzilla.wpkg.org/show_bug.cgi?id=176 Marco Gaiarin g...@sv.lnf.it changed: What|Removed |Added CC||g...@sv.lnf.it --- Comment #1 from Marco Gaiarin g...@sv.lnf.it 2009-10-05 10:00:42 --- I can absolutly confirm that. Same error. Windows XP sp3 fresh updated. I've noted also that if i disable offline mode WPKGClient works, but the process remains in a spurious state, eg i've to kill WPKGSrv.exe process to be able to restart it. Also in my organization i use mainly the 'oldstable' 1.2.1 version, and on some poratble system the 'beta' 1.3.6 with no trouble at all. -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 177] New: Local install flag
http://bugzilla.wpkg.org/show_bug.cgi?id=177 Summary: Local install flag Product: WPKG Version: 1.1.2 Platform: PC OS/Version: Windows XP Status: NEW Severity: enhancement Priority: P2 Component: wpkg.js AssignedTo: r.me...@wpkg.org ReportedBy: ftroj...@smi-softmark.de QAContact: wpkg-users@lists.wpkg.org Some time ago I missed the feature of packages marked as locally installed, which came to my mind again as a possible solution for bug 175, so I'll try to explain that here. Preference: wpkg.js /install:package name does install a package locally, wpkg.js /remove:package name does remove that same package. Problem: But wpkg.js /synchronize does - logically - remove all packages which are not in hosts/profiles database. So, locally installed packages are automagically removed from the system as intended. Sometimes, e.g. for testing reasons or to give a special user the possibility to install a package himself, I think it would be essential to have a manually installed package not automagically removed from the system when synchronizing. Solution: wpkg.js /install:package name /local or wpkg.js /install:package name /persistent marks a package in local wpkg.xml as package id='Firefox' name='Mozilla Firefox' revision='3.5.0' priority='50' reboot='false' local='true' ... /package or package id='Firefox' name='Mozilla Firefox' revision='3.5.0' priority='50' reboot='false' persistent='true' ... /package For the difference between local and persistent I could imagine that for local packages the usual upgrade mechanism of wpkg.js /synchronize is used, but persistent packages never upgrade automagically, so I can have a system with a special revision of a package until I upgrade this system manually or the package is assigned to this host by hosts.xml/profiles.xml. Keep up with your good work! Regards, Falko -- Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] wrapper settings path mismatch problem
Hi, I need some help to try and rectify a problem, of my making! I manually edited the settings.xml to change from server1 to server2 but missed the wrapper path and only changed the settings paths. Now I have the path for the wrapper \\server1\wpkg\wpkg.js and the settings/software as \\server2\wpkg\settings.xml so wpkg fails. Has anyone got a suggestion on how to change these? Where are the wpkgservice settings stored? Registry? Xml file? As I could try and change it via a DS group policy. BTW, thanks to everyone for the help on the downgrade version stuff, it worked great. Thanks Paul -- Paul McGrath, IT Manager, Leeds Institute of Molecular Medicine, St James's University Hospital, Beckett Street, Leeds, LS9 7TF, UK Ext.: Uni - 38630, NHS - (89)38630 Tel.: +44 113 34 38630 Email...: j.p.mcgr...@leeds.ac.uk Homepage: http://www.limm.leeds.ac.uk - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] Strange error...
Mandi! Rainer Meier In chel di` si favelave... Microsoft (R) Windows Script Host Versione 5.7 Seems to be the latest version. Maybe re-installing it (http://www.microsoft.com/downloads/details.aspx?FamilyID=47809025-D896-482E-A0D6-524E7E844D81displaylang=en) could help. Just try. ...my first try, but the installer say: «you have just the latest version, thanks.». ;((( Seems there's no way to reinstall... Which version of wpkg.js are you running? 1.0.4 (i'm upgrading now) and on line 4252 there's: var tempLogPath = new ActiveXObject(WScript.Shell).ExpandEnvironmentStrings(%TEMP%\\wpkg-logInit.log); Try re-installing cscript and attach a full WPKG debug log (if it does not dash out directly at startup before it writes anything). ...seems that wpkg does not produce any output at all. ;( -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia''http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) marco.gaiarin(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA! http://www.lanostrafamiglia.it/chi_siamo/5xmille.php (cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA) - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] revision number problem
Mandi! Rainer Meier In chel di` si favelave... This is true as well and has been introduced quite recently by a heavy improvement of the version comparison algorithm. A little, probably unrelated question. There's a separator defined for 'internal subrevision'? EG, for now i use, for firefox: 30141 for 3.0.14 internal revision 1; i use internal revision because i'm human and male, so i make mistakes ;), and when i do that, i can fix the packege augmenting only the internal revision. Can i write now as: 3.0.14:1 or whatever separator i like, : , ; , -, |, ... different from dot to mark them explicitly as 'internal revision'? Thanks. -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia''http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) marco.gaiarin(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA! http://www.lanostrafamiglia.it/chi_siamo/5xmille.php (cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA) - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] Strange error...
Hi Marco, Marco Gaiarin wrote: ...my first try, but the installer say: «you have just the latest version, thanks.». ;((( Seems there's no way to reinstall... Maybe it checks some (existing) registry keys and then exits. ProcessMonitor might help to detect the right entries, remove them and then re-install it. But this is quite messy - especially since we should assume that WSH is installed properly. Which version of wpkg.js are you running? 1.0.4 (i'm upgrading now) and on line 4252 there's: var tempLogPath = new ActiveXObject(WScript.Shell).ExpandEnvironmentStrings(%TEMP%\\wpkg-logInit.log); Upgrading to 1.1.2 is recommended. However the same functions are used in WPKG 1.1.2 too. I guess it's somehow unable to locate ExpandEnvironmentStrings on the WScript.Shell object. Why? No clue :-( Try re-installing cscript and attach a full WPKG debug log (if it does not dash out directly at startup before it writes anything). ...seems that wpkg does not produce any output at all. ;( Well, ExpandEnvironmentStrings is used to expand the location where the log file is written. So no chance for WPKG to initiate the log part. It's not the first time that something like this happens. I ought to remember that a similar problem has been reported once but I think this guy just re-installed the machine and the problem was gone. Maybe you can trace execution with ProcessMonitor - see if it (cscript.exe) tries to access some files which are missing (or registry entries). Just do it if you have the patience to do so. Alternatively just re-install the machine. If you're able to trace it down to the root cause we would be interested to hear what was causing it. br, Rainer - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] revision number problem
Hi Marco, Marco Gaiarin wrote: A little, probably unrelated question. There's a separator defined for 'internal subrevision'? EG, for now i use, for firefox: 30141 for 3.0.14 internal revision 1; i use internal revision because i'm human and male, so i make mistakes ;), and when i do that, i can fix the packege augmenting only the internal revision. Can i write now as: 3.0.14:1 or whatever separator i like, : , ; , -, |, ... different from dot to mark them explicitly as 'internal revision'? Well as far as I remember the algorithm everything which is not a number can be used as a separator (words, characters, punctuation marks) So yes, a version number of 3.0.14:1 would be allowed I think the evaluation would be as follows: 3.0.14 - 3.0.14:1 is newer 3.0.14:1 - 3.0.14:2 is newer 3.0.14:1 - 3.0.15 is newer 3.0.14:1 - 3.0.15:1 is newer However this punctuation is very uncommon (I've never seen that before). I suggest you to just add another period mark: 3.0.14.1 What I've seen some times is a release marker: 3.0.14r1 which shouold be supported by the algorithm: 3.0.14r1 is newer than 3.0.14 3.0.14r2 is newer than 3.0.14r1 3.0.15 is newer than 3.0.14r50 But I would prefer the simple punctuated notation above: 3.0.14.# If in doubt which result the version comparison evaluation yields just open the debug log file and look for Comparing version: 'x' = 'y'. entries. br, Rainer - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] wrapper settings path mismatch problem
Mandi! Falko Trojahn In chel di` si favelave... usually I do such upgrade things using a package, see attached. A little question: why use: cmd /c start /min msiexec on install and simply only 'msiexec' on upgrade? I'm curious... ;))) -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia''http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) marco.gaiarin(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA! http://www.lanostrafamiglia.it/chi_siamo/5xmille.php (cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA) - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] revision number problem
Mandi! Rainer Meier In chel di` si favelave... However this punctuation is very uncommon (I've never seen that before). I I will use ':' just for it's 'strangness': well suited to mark and 'internal' subrevision number... Many thanks. -- dott. Marco Gaiarin GNUPG Key ID: 240A3D66 Associazione ``La Nostra Famiglia''http://www.sv.lnf.it/ Polo FVG - Via della Bontà, 7 - 33078 - San Vito al Tagliamento (PN) marco.gaiarin(at)sv.lnf.it tel +39-0434-842711 fax +39-0434-842797 Dona il 5 PER MILLE a LA NOSTRA FAMIGLIA! http://www.lanostrafamiglia.it/chi_siamo/5xmille.php (cf 00307430132, categoria ONLUS oppure RICERCA SANITARIA) - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
Re: [wpkg-users] wrapper settings path mismatch problem
Marco Gaiarin schrieb: Mandi! Falko Trojahn In chel di` si favelave... usually I do such upgrade things using a package, see attached. A little question: why use: cmd /c start /min msiexec on install and simply only 'msiexec' on upgrade? I'm curious... ;))) Hmm. I mean to remember a time where we had the transition from wpkg_start.bat-service to WPKG Client and there was another package for removing the old service. Perhaps this was a workaround for some timing issue ... don't know. Perhaps this can be removed. Falko - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
[wpkg-users] [Bug 177] Local install flag
http://bugzilla.wpkg.org/show_bug.cgi?id=177 --- Comment #3 from Rainer Meier r.me...@wpkg.org 2009-10-05 13:13:59 --- a) If the user has no right to install applications manually, but he can queue an installation via e.g. a tool similar to wpkginst where he has a choice of applications for installation, this would make sense. True. Such a tool would have to be developed first. I think it would require a WPKG-installer service running with correct privileges and a user-GUI which allows to send commands like install package x to the service which uses WPKG to install it. b) trying out package installation at a certain system which survives a reboot would make really sense to me Well, I thought my reply was clear. I _am_ actually planning that these packages installed manually (which do not belong to the profile) survive the next synchronization. I even think these packages should be handled and upgrade by WPKG from that point in time - just like any other package assigned by the administrator. That's why my differentiation between local and persistent flags. But you are right, perhaps we have to control by hosts/profiles if a host may or may not install persistent packages locally. I am quite sure some additional permission management would have to be introduced. But for the beginning I target only a simple implementation where users could add packages manually which stay on the host (persistently) and are updated by synchronization. Everything else might be added when we have some client-side management tool available. For the time being you would anyway need administrator privileges to use WPKG directly. The advantage at the beginning would be that local admins could install the package from the repository instead of installing it manually from a downloaded file - and it would be updated by the administrator of WPKG. No. At the moment, if there is no additional flag in wpkg.xml for this package, and the synchronization runs, this package is just uninstalled, because it is not assigned to this host by hosts/profiles.xml. Yes, this is the _current_ implementation. But I have to modify it anyway to insert another attribute to the package when it's added to the local wpkg.xml. Just as a reminder for WPKG that this package has been manually added and should be maintained in addition to the packages in the profile. I just think we don't need an additional command-line switch for this. Packages which are added manually by using WPKG /install switch can be maintained by WPKG starting from the install date. See my note above. And _if_ a user has the right to install software, why shouldn't he use the wpkg mechanism but do it on its own? The advantage of WPKG is clearly to keep the installed packages up-to-date by automatic synchronization and roll-out by a central package manager. However only a few users know about this and even fewer will care about. The average user which has admin privileges just installs the same way as he/she is doing on the home computer - just download and install. So the way to go would for sure be to disallow users to install any software and provide a tool which allows to select any available software from the WPKG repository and apply it. WPKG will install it and the WPKG administrator will maintain it and provide updates. If a user needs a software which is not in the WPKG repository the user needs to contact the administrator ro provide it. Actually this would be possible already today. I don't know if it could be included in WPKGExrpess but it could provide a user-login for all users and provide access to define the profile for the host from which WPKGExpress is accessed. This would allow users to configure a custom profile for the host they are working on. Even without requiring any modification in WPKG. Yes and no. I think that a local or persistent flag in wpkg.xml would prevent manually installed packages from being removed by synchronization and could be easily implemented - could even help regarding Simon's bug 175 requirements. For sure it needs at least one additional attribute which flags that the package has been added manually and should be maintained by WPKG. I was mainly saying that I think we don't need additional /local or /persistent flags which bloats the user interface and packages installed by users using the /install flag should always be persistent (if the user just needs it for one session he could remove it afterwards). The same applies to the /local flag. If /install is used manually the package is anyway a local package. So I think only only one attribute in the package is needed... package id='Firefox' name='Mozilla Firefox' revision='3.5.0' priority='50' reboot='false' local='true' ... So WPKG just sets local=true for all packages installed via /install which are not part of the profile yet. All local=true packages are not removed during synchronization but are updated instead exactly like packages in the
Re: [wpkg-users] [Bug 175] Test return value of removeSettingsNode function
Chris Wilcox wrote: I also use WPKG across 16 schools. One of the first things I did when trialling and now using wpkg live was dredge out an old and unused PC capable of running XP Pro and set this up as a test workstation for wpkg packages before I roll things out to the live networks. :) I know all the workarounds - I'm trying to not have to do them as none are the same as the real world :) regards Simon -- View this message in context: http://www.nabble.com/-Bug-175--New%3A-Test-return-value-of-removeSettingsNode-function-tp25737803p25751042.html Sent from the WPKG - Users mailing list archive at Nabble.com. - wpkg-users mailing list archives http://lists.wpkg.org/pipermail/wpkg-users/ ___ wpkg-users mailing list wpkg-users@lists.wpkg.org http://lists.wpkg.org/mailman/listinfo/wpkg-users
