headers
Mike Burgener | 1 Apr 2011 15:35
Favicon

strange network printer share print driver deployment issue

Hi all,

very happy with wpkg, but i have a very very strange issue at the 
moment.

Wen want to deploy printer drivers using wpkg during boot, there is a 
script which is executed by wpkg:

cmd-script
http://pastebin.com/A0VpTEUp

the wpkg-package file:
http://pastebin.com/xcqW5HnJ

if i manually run the .cmd file, it works.

Server on which the script is run is "servera" but the printers rely on 
"serverb", if i'm logged in using a network user the script works, 
however if i run it without network user the .cmd just hangs while 
executing the first "rundll" part.

However i tried to implement a workaround by doing the "net use" first, 
but this did not help either.

But if i do the "net use" first while testing without wpkg as a local 
user, it does fix it.

The strange thing on some workstations it seems to function but on other 
not and all seem to have the same installation.
(Continue reading)

Permalink | Reply | 1 comment |
headers
Rainer Meier | 4 Apr 2011 09:09
Favicon

Re: strange network printer share print driver deployment issue

Hi Mike,

On 01.04.2011 15:35, Mike Burgener wrote:
> very happy with wpkg, but i have a very very strange issue at the 
> moment.
> 
> Wen want to deploy printer drivers using wpkg during boot, there is a 
> script which is executed by wpkg:
> 
> cmd-script
> http://pastebin.com/A0VpTEUp
> 
> the wpkg-package file:
> http://pastebin.com/xcqW5HnJ
> 
> if i manually run the .cmd file, it works.
> 
> Server on which the script is run is "servera" but the printers rely on 
> "serverb", if i'm logged in using a network user the script works, 
> however if i run it without network user the .cmd just hangs while 
> executing the first "rundll" part.
> 
> However i tried to implement a workaround by doing the "net use" first, 
> but this did not help either.
> 
> But if i do the "net use" first while testing without wpkg as a local 
> user, it does fix it.
> 
> The strange thing on some workstations it seems to function but on other 
> not and all seem to have the same installation.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Dehennin | 4 Apr 2011 14:47
Picon
Favicon

Re: WPKG Development Status

"cleitet <at> gmail.com" <cleitet <at> gmail.com> writes:

[...]

> - Have an easy to use interface for configuration that makes it easy to
> distribute the configuration to many clients (still trying and failing on
> this)

We use a git repository to distribute the cmd scripts and the WPKG
files, works pretty well ;-)

> - Optionally run in system tray and check for updated packages at regular
> intervals. Inform users about updates and prompt them with alternatives.
> (the platform is designed to be able do this)

Here, we do not want to have messages in system tray. Our users get
bored by such ToolTips.

> - Hopefully be able to install software at shutdown with feedback to user
> (this is not easily achievable AFAIK, as Windows does not have an API for
> giving information to users at shutdown)

We run WPKG client at shutdown to avoid a delay at startup, our users
are more inclined to have a shutdown delay rather than a startup one.

I wonder how the windows "install updates and shutdown" works, seems
that we can register[1] an application to block the shutdown process.

The user can force the shutdown to occur, if so, the client can force a
run at the next startup if it was canceled by the user (like the windows
(Continue reading)

Permalink | Reply | 0 comments |
headers
bugzilla-daemon | 5 Apr 2011 10:23
Favicon

[Bug 203] New: Argument parsing misbehaves

http://bugzilla.wpkg.org/show_bug.cgi?id=203

           Summary: Argument parsing misbehaves
           Product: WPKG
           Version: 1.1.2
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: wpkg.js
        AssignedTo: mangoo <at> wpkg.org
        ReportedBy: mycroes <at> gmail.com
         QAContact: wpkg-users <at> lists.wpkg.org

WPKG doesn't reject any arguments, even if it doesn't know them. For instance,
if a use would use '/norestart', WPKG would do the same as when '/norestart'
was omitted, because what the user actually meant probably was '/noreboot'.

The proper solution would be to bail on unknown arguments so the user knows
something is not working as expected.

--

-- 
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/
Permalink | Reply | 1 comment |
headers
bugzilla-daemon | 5 Apr 2011 10:29
Favicon

[Bug 204] New: Allow non-scripted installation of more than one package without specifying profile

http://bugzilla.wpkg.org/show_bug.cgi?id=204

           Summary: Allow non-scripted installation of more than one
                    package without specifying profile
           Product: WPKG
           Version: 1.1.2
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: wpkg.js
        AssignedTo: mangoo <at> wpkg.org
        ReportedBy: mycroes <at> gmail.com
         QAContact: wpkg-users <at> lists.wpkg.org

I currently haven't found a way to install multiple packages at once without
invoking WPKG multiple times. My proposal would be support for either of the
following:

Support multiple install options in current argument style:
wpkg.js /install:dotnet3 /install:rdp /install:ie8

Support operation modes (as seen in apt, portage, git, subversion, etc.):
wpkg.js /install dotnet3 rdp ie8
wpkg.js /remove rdp dotnet3
wpkg.js /<action> [<package_name> ...]

--

-- 
Configure bugmail: http://bugzilla.wpkg.org/userprefs.cgi?tab=email
(Continue reading)

Permalink | Reply | 1 comment |
headers
Dave Ewart | 5 Apr 2011 10:53
Picon
Picon

Tips for testing new/upgraded packages before general deployment

Hello,

I've been using WPKG for years now and have found it very useful.
However, I have a question relating to how one tests packages before
making them generally available.

For new package installs, I've got it sorted.  A simplified profiles.xml
looks like this when I'm testing "app4".

<profile id="typical">
  <package package-id="app1" />
  <package package-id="app2" />
  <package package-id="app3" />
</profile>

<profile id="testing">
  <depends profile-id="typical" />
  <package package-id="app4" />
</profile>

In this state, only my testing machines (typically only VMs which I can
snapshot and rollback if/when testing fails) pick up 'app4'.  Once I've
got my package definition correct and working for 'app4', I move the
package into the 'typical' profile, like this:

<profile id="typical">
  <package package-id="app1" />
  <package package-id="app2" />
  <package package-id="app3" />
  <package package-id="app4" />
(Continue reading)

Permalink | Reply | 3 comments |
headers
Natxo Asenjo | 5 Apr 2011 12:26
Picon

Re: Tips for testing new/upgraded packages before general deployment

On Tue, Apr 5, 2011 at 10:53 AM, Dave Ewart <davee <at> ceu.ox.ac.uk> wrote:

[knip]

> In this state, only my testing machines (typically only VMs which I can
> snapshot and rollback if/when testing fails) pick up 'app4'.  Once I've
> got my package definition correct and working for 'app4', I move the
> package into the 'typical' profile, like this:
>
> <profile id="typical">
>  <package package-id="app1" />
>  <package package-id="app2" />
>  <package package-id="app3" />
>  <package package-id="app4" />
> </profile>
>
> <profile id="testing">
>  <depends profile-id="typical" />
> </profile>
>
> I don't think the above is anything revolutionary.  It works and works
> well.  The 'typical' machines only see 'app4' once I'm happy it's ready
> for full deployment.
>
> The issue I have, however, is if I want to test the *upgrade* for an
> existing, already deployed app.  Let's say, in the above example, I have
> an upgrade for 'app2'.  I want to be sure that the upgrade works, using
> my 'testing' VM, before I make it available to the 'typical' group.
>
> How do people do that, generally?  My main constraint is that there must
(Continue reading)

Permalink | Reply | 2 comments |
headers
Dave Ewart | 5 Apr 2011 17:33
Picon
Picon

Re: Tips for testing new/upgraded packages before general deployment

On Tuesday, 05.04.2011 at 12:26 +0200, Natxo Asenjo wrote:

> > [...]
> >
> > The issue I have, however, is if I want to test the *upgrade* for an
> > existing, already deployed app.  Let's say, in the above example, I
> > have an upgrade for 'app2'.  I want to be sure that the upgrade
> > works, using my 'testing' VM, before I make it available to the
> > 'typical' group.
> >
> > How do people do that, generally?  My main constraint is that there
> > must be no circumstances under which the 'typical' group can pick up
> > on the upgrade until I've fully tested it.  The 'typical' group
> > should stay with the non-upgraded 'app2' (or only install the older,
> > non-upraded version of 'app2' if they've not seen it before).
> 
> what we do is have serveral (mercurial) repositories: testing,
> staging, production (for instance).
> 
> The testing vm's get their configs from \\host\share\wpkg-testing, the
> staging machines from \\host\share\wpkg-testing and the production
> from \\host\share\wpkg-production.
> 
> [...]

Ah, I understand the general approach.  I hadn't considered the
possibility of using multiple repositories in this way.  Sounds like a
good idea.

Many thanks...
(Continue reading)

Permalink | Reply | 1 comment |
headers
John Danks | 5 Apr 2011 18:55
Picon

Re: Tips for testing new/upgraded packages before general deployment

On Tue, Apr 5, 2011 at 8:33 AM, Dave Ewart <davee <at> ceu.ox.ac.uk> wrote:
> On Tuesday, 05.04.2011 at 12:26 +0200, Natxo Asenjo wrote:
>
> Ah, I understand the general approach.  I hadn't considered the
> possibility of using multiple repositories in this way.  Sounds like a
> good idea.

I do a similar but simpler approach. I have one machine with WPKG
Client pulling from \\server\WPKG-test. I make changes to the XML
files in that folder and when I'm confident they are ready then I copy
them over to \\server\WPKG. It's handy to be able to run a diff
between the directories to see your exact changes too.
-------------------------------------------------------------------------
wpkg-users mailing list archives >> http://lists.wpkg.org/pipermail/wpkg-users/
Permalink | Reply | 0 comments |
headers
Nick Elmendorf | 5 Apr 2011 18:52

Re: Tips for testing new/upgraded packages before general deployment

RE: Tips for testing new/upgraded packages before general deployment

I have a idea for what could work.

We also use VM's for testing WPKG packages and the package upgrades.

What you can do is make a second profile for WPKG. So you start by having:

Profile A: Normal profile you've been using
Profile B: Testing profile.

Profile A remains unchanged almost all of the time, except when your ready to include good code
Profile B changes all the time, as you test, upgrade and add new packages. 

Now for your upgrades you keep your packages as they are. When you want to upgrade, say Firefox, you open your
firefox.xml package, do a save as, and rename it test_firefox.xml. Now, before you
upgrade/configure/test test_firefox.xml you need to do one more thing. 

Open your new testing profile, and copy over everything from your normal profile. Save it. Run it. Now you
have two environments which should be identical, your normal production profile and your test profile.
Now go into the test profile, change firefox.xml to test_firefox.xml and work the package until it works. 

Now in the host file make a new entry which points to the computer name of "testing VM" or "testing machine"
and give it your testing profile.

Once its good, copy the good code into firefox.xml, which your good profile is already pointing to and now it
works. Don't forget to roll back the snap shot on your VM to match your new environment, and make sure the
profiles match and now your good to go for your next upgrade/test.

Hopefully that works for what your looking for. If not let me know and I'll be happy to answer any questions.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane