opsi-setup-detector - customizing?
opsi-setup-detector - customizing?
to disclose my intentions,
i built a custom opsiscript framwork (various opsiscripts with common code segments to be used in packages), and i need a template system to build basic opsi packages. i already have sort of built a custom IDE for opsi in jedit using various plugins, and it works, but it tends to be a real mess at times, also a rather awkward way to work with preexisting code segments/templates.
so i am looking for alternative ways, especially one i can easily impart on to my workmates.
after taking another look at opsi-setup-detector, in combination with package builder, it seems not too far from what i need, but it still lacks quite a bit.
thus i would like to ask if i may customize it (more specifically, for now i would like to provide a way to add custom setup detection patterns and additional usage cases and a way to import more then one setup into one package, and of course make it work with my existing opsiscript ecosystem). i would gladly share the results once i get it to a usable level.
if the answer to that is yes,
where can i find the source files for the current opsi-setup-detector release?
i found this: https://github.com/opsi-org/lazarus/tre ... updetector, but it appears to be a rather old version (4.0.5.124 if i got it right)
it appears to be written in freepascal using lazarus?
i built a custom opsiscript framwork (various opsiscripts with common code segments to be used in packages), and i need a template system to build basic opsi packages. i already have sort of built a custom IDE for opsi in jedit using various plugins, and it works, but it tends to be a real mess at times, also a rather awkward way to work with preexisting code segments/templates.
so i am looking for alternative ways, especially one i can easily impart on to my workmates.
after taking another look at opsi-setup-detector, in combination with package builder, it seems not too far from what i need, but it still lacks quite a bit.
thus i would like to ask if i may customize it (more specifically, for now i would like to provide a way to add custom setup detection patterns and additional usage cases and a way to import more then one setup into one package, and of course make it work with my existing opsiscript ecosystem). i would gladly share the results once i get it to a usable level.
if the answer to that is yes,
where can i find the source files for the current opsi-setup-detector release?
i found this: https://github.com/opsi-org/lazarus/tre ... updetector, but it appears to be a rather old version (4.0.5.124 if i got it right)
it appears to be written in freepascal using lazarus?
Zuletzt geändert von larsg am 15 Mär 2018, 08:53, insgesamt 1-mal geändert.
Re: opsi-setup-detector - customizing?
edit: ups wrong section for german
^there goes again.
^there goes again.
- n.wenselowski
- Ex-uib-Team
- Beiträge: 3194
- Registriert: 04 Apr 2013, 12:15
Re: opsi-setup-detector - customizing?
Hi,
since this involves building your own binaries and changing the source I've moved this topic. Time to fill the developer forum
I also passed word along to the responsible developer as he can give you better insights.
Bye
Niko
since this involves building your own binaries and changing the source I've moved this topic. Time to fill the developer forum
I also passed word along to the responsible developer as he can give you better insights.
Bye
Niko
Code: Alles auswählen
import OPSI
Re: opsi-setup-detector - customizing?
Hi larsg,
I am the developer of the opsi-setup-detector.
I am working on a complete redesign of the opsi-setup-detector to make it easier to integrate more different installers.
But this development code is not compilable and published right now.
Please tell me a little bit more in detail what you are planning to do, so that I can guide you if it better to wait for the new source or to implement it in the old one.
cheers
d.oertel
I am the developer of the opsi-setup-detector.
Yes thats is both right.i found this: https://github.com/opsi-org/lazarus/tre ... updetector, but it appears to be a rather old version (4.0.5.124 if i got it right)
it appears to be written in freepascal using lazarus?
I am working on a complete redesign of the opsi-setup-detector to make it easier to integrate more different installers.
But this development code is not compilable and published right now.
Please tell me a little bit more in detail what you are planning to do, so that I can guide you if it better to wait for the new source or to implement it in the old one.
cheers
d.oertel
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
http://www.opsi.org
For productive opsi installations we recommend support contracts.
http://www.uib.de
http://www.opsi.org
Re: opsi-setup-detector - customizing?
Hi,
how long do you think you will need for the redesign?
it's hard for me to explain, as i don't really have it all fleshed out yet, but this is the basic idea:
i have a bunch of scripts with commonly used sections, split up by purpose/application/setup-type.
for every setup-type i have predefined sections for various install/uninstall scenarios and of course exitcode-handling.
i also have some for driver handling, microsoft updates, custom client audits, and already plan a few more, packed shedule is what's capping me atm.
so my main goal in every opsi package (besides functionality) is maximum standardization and quality, and for that, using templates seem to be best practise.
i already tried to build templates for every possible scenario, but it's just too many variables to consider - (multipe?) setup types, intall?/uninstall?/update?/configure user?/configure system? 32-/64-bit/both? does the setup require a config file? does the setup provide log file generation with or without custom path? ...
so i came up with the idea of dynamic templates, where i have blocks that are always the same in every package, except a few minor details, which can be assembled like building blocks.
in my packages, this is what a typical block would look like for an installshield setup with iss-file:
for msi, the only difference would be - setupfile is a msi-file, (if at all needed) configfile is a mst-file, and it's either WinBatch_install_msi_standard or WinBatch_install_msi_config to be called, depending on if a mst-file is used. of course, every block relies on specifc variables to be used, that's part of my standard.
i envision dragging the setup-files on the opsi-setup-detector window, which then parses the setup type and (if possible) which bit-version it applies to, and also asks for desired actions to implement all the neccessery basic template blocks.
anyways, the main issue is see - i'd need to be able to fully customize everything, as my intended usage likely goes far beyond of what the average scripter needs. at least until it's all running as intended.
that's why i ask if i may customize/fork the application. as said, i would gladly share the results, provided it is at all usable...
how long do you think you will need for the redesign?
it's hard for me to explain, as i don't really have it all fleshed out yet, but this is the basic idea:
i have a bunch of scripts with commonly used sections, split up by purpose/application/setup-type.
for every setup-type i have predefined sections for various install/uninstall scenarios and of course exitcode-handling.
i also have some for driver handling, microsoft updates, custom client audits, and already plan a few more, packed shedule is what's capping me atm.
so my main goal in every opsi package (besides functionality) is maximum standardization and quality, and for that, using templates seem to be best practise.
i already tried to build templates for every possible scenario, but it's just too many variables to consider - (multipe?) setup types, intall?/uninstall?/update?/configure user?/configure system? 32-/64-bit/both? does the setup require a config file? does the setup provide log file generation with or without custom path? ...
so i came up with the idea of dynamic templates, where i have blocks that are always the same in every package, except a few minor details, which can be assembled like building blocks.
in my packages, this is what a typical block would look like for an installshield setup with iss-file:
Code: Alles auswählen
Message "Installiere - "+$ProductName$+" - Version "+$ProductVersion$+" - Architektur "$SystemArchitectureBit$"-Bit"
SetActionProgress "Installing"
Comment "Run Setup"
Set $SetupFile$ = $SetupDir$+"\setup.exe"
Set $ConfigFile$ = $SetupDir$+"\setup.iss"
Sub_get_timestamp
Set $LogFile$ = $LogDir$+"\"+$TimeStamp$+"_"+StringReplace($ProductName$," ","-")+"_"+StringReplace($ProductVersion$,".","-")+"_Install.log"
WinBatch_install_ish_config /WaitOnClose
i envision dragging the setup-files on the opsi-setup-detector window, which then parses the setup type and (if possible) which bit-version it applies to, and also asks for desired actions to implement all the neccessery basic template blocks.
anyways, the main issue is see - i'd need to be able to fully customize everything, as my intended usage likely goes far beyond of what the average scripter needs. at least until it's all running as intended.
that's why i ask if i may customize/fork the application. as said, i would gladly share the results, provided it is at all usable...
Re: opsi-setup-detector - customizing?
So any news on this?d.oertel hat geschrieben: Please tell me a little bit more in detail what you are planning to do, so that I can guide you if it better to wait for the new source or to implement it in the old one.
With your permission, I would just like to see what i can do with the latest stable source code.
All work done will be shared, so you can pick the parts you deem good enough for your own release.
Re: opsi-setup-detector - customizing?
Hi,
I'm sorry but the old version was in SVN and was maintained be a different person.
In the context of switching this project back to me and switching from svn to git
some versions were accidently lost.
The youngest of the old versions you will find here: https://download.uib.de/opsi4.0/experim ... mitted.zip
But as I told you - I' am working on a new version with a complete redesigned data structure.
I think it will take one or two weeks until the first version of the new development will be visible at
https://github.com/opsi-org/lazarus/tre ... iptstarter
regards
d.oertel
I'm sorry but the old version was in SVN and was maintained be a different person.
In the context of switching this project back to me and switching from svn to git
some versions were accidently lost.
The youngest of the old versions you will find here: https://download.uib.de/opsi4.0/experim ... mitted.zip
But as I told you - I' am working on a new version with a complete redesigned data structure.
I think it will take one or two weeks until the first version of the new development will be visible at
https://github.com/opsi-org/lazarus/tre ... iptstarter
regards
d.oertel
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
http://www.opsi.org
For productive opsi installations we recommend support contracts.
http://www.uib.de
http://www.opsi.org
Re: opsi-setup-detector - customizing?
Well the version equals to the currently provided opsi package version, so that's fair enough (:d.oertel hat geschrieben: In the context of switching this project back to me and switching from svn to git
some versions were accidently lost.
That sounds good, i will see what's up with that before i mess things up myselfd.oertel hat geschrieben: But as I told you - I' am working on a new version with a complete redesigned data structure.
I think it will take one or two weeks until the first version of the new development will be visible at
https://github.com/opsi-org/lazarus/tre ... iptstarter