Feature changed by: Thomas Schmidt (digitaltomm) Feature #305842, revision 3 Title: Provide RPM Update Server to Update All openSUSE/SLED Workstations - openFATE: Unconfirmed + openSUSE-11.2: New Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: *Please be Patient - This is my First FATE request* Definitions in this Submission Workstation == Any openSUSE/SLED installation that functions without direct server support Installation Server == Any designated PC that holds a repository for the complete RPM's contained at time of software Release. Update Server == Any designated PC that holds a repository(s) that contain online update RPM's The 'Server' would be accessible by normal NFS... et al Services currently available. Current Situation The Installation of a PC with openSUSE/SLED requires a huge number of Online Updates a situation that may never change whilst development continues. The Installation of openSUSE has the ability to perform many NFS Installations at one time whilst being able to create 1 repository server for the entire Installation RPM's for future addition of features and groups not included in the base installation. Feature Request Along the same notion of an NFS Installation I propose that we an Installation Server or Other to be an Update Server which downloads ALL RPM updates as they become available. Each Workstation then selects Online Updates from the Update Server per chosen update check cycle period. In this way each workstation needs only to connect with the Update Server rather than each workstation downloading its required updates. This has the potential to cut update traffic by the number of workstations installed on a LAN and this weighed against the traffic of downloading ALL updates and the traffic on ALL Online update Server Repositories and Mirrors external to the LAN. The concept is notedly simple however this has a huge technical repercussion and link to FATE #120340. This concept is open for addition to FATE #120340 or it can stand alone at the discretion of Novell.DE Whilst this concept is created by the author the technical impact/problems will require much input from Novell.De and Suse.DE and the author. Discussion: #1: Scott Couston (zczc2311) (2009-02-10 02:37:07) I wish the carriage returns CR held from initial text - Can be have a CR Button - Please edit initial description if required. Can we also have a preview before commit comments/initial entry -- openSUSE Feature: https://features.opensuse.org/305842

Feature changed by: Rémy Marquis (Spyhawk) Feature #305842, revision 6 Title: Provide RPM Update Server to Update All openSUSE/SLED Workstations openSUSE-11.2: New Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: - *Please be Patient - This is my First FATE request* Definitions in - this Submission Workstation == Any openSUSE/SLED installation that - functions without direct server support Installation Server == Any - designated PC that holds a repository for the complete RPM's contained - at time of software Release. Update Server == Any designated PC that - holds a repository(s) that contain online update RPM's The 'Server' - would be accessible by normal NFS... et al Services currently - available. Current Situation The Installation of a PC with - openSUSE/SLED requires a huge number of Online Updates a situation that - may never change whilst development continues. The Installation of - openSUSE has the ability to perform many NFS Installations at one time - whilst being able to create 1 repository server for the entire - Installation RPM's for future addition of features and groups not - included in the base installation. Feature Request Along the same - notion of an NFS Installation I propose that we an Installation Server - or Other to be an Update Server which downloads ALL RPM updates as they - become available. Each Workstation then selects Online Updates from the - Update Server per chosen update check cycle period. In this way each - workstation needs only to connect with the Update Server rather than - each workstation downloading its required updates. This has the - potential to cut update traffic by the number of workstations installed - on a LAN and this weighed against the traffic of downloading ALL - updates and the traffic on ALL Online update Server Repositories and - Mirrors external to the LAN. The concept is notedly simple however this - has a huge technical repercussion and link to FATE #120340. This - concept is open for addition to FATE #120340 or it can stand alone at - the discretion of Novell.DE Whilst this concept is created by the - author the technical impact/problems will require much input from - Novell.De and Suse.DE and the author. + *Please be Patient - This is my First FATE request* + Definitions in this Submission + * Workstation : Any openSUSE/SLED installation that functions without + direct server support + * Installation Server : Any designated PC that holds a repository for + the complete RPM's contained at time of software Release. + * Update Server : Any designated PC that holds a repository(s) that + contain online update RPM's The 'Server' would be accessible by normal + NFS... et al Services currently available. + Current Situation + The Installation of a PC with openSUSE/SLED requires a huge number of + Online Updates a situation that may never change whilst development + continues. The Installation of openSUSE has the ability to perform many + NFS Installations at one time whilst being able to create 1 repository + server for the entire Installation RPM's for future addition of + features and groups not included in the base installation. + Feature Request + Along the same notion of an NFS Installation I propose that we an + Installation Server or Other to be an Update Server which downloads ALL + RPM updates as they become available. Each Workstation then selects + Online Updates from the Update Server per chosen update check cycle + period. In this way each workstation needs only to connect with the + Update Server rather than each workstation downloading its required + updates. This has the potential to cut update traffic by the number of + workstations installed on a LAN and this weighed against the traffic of + downloading ALL updates and the traffic on ALL Online update Server + Repositories and Mirrors external to the LAN. The concept is notedly + simple however this has a huge technical repercussion and link to FATE + #120340. This concept is open for addition to FATE #120340 or it can + stand alone at the discretion of Novell.DE Whilst this concept is + created by the author the technical impact/problems will require much + input from Novell.De and Suse.DE and the author. Discussion: #1: Scott Couston (zczc2311) (2009-02-10 02:37:07) I wish the carriage returns CR held from initial text - Can be have a CR Button - Please edit initial description if required. Can we also have a preview before commit comments/initial entry #2: Scott Couston (zczc2311) (2009-02-18 05:43:26) I had envisaged that we could add another option to the Miscellaneous Section of Yast. We already have a wizard to create and install server so we can use much of the same code to create an Online Patch Update Server. Naming convention should apply to reflect Version and Architecture. Priority must also be provided and a 'wake PC' option of PC is not turned on. The very tricky bit to to set up a cron job to gather ALL Updates for the user indicated version and architecture. On the client side I would suggest we add another check box to Software Repositories to turn on and off and take regard for priority and create an NFS Client if and then browse for the update Servers name. In the absence of a matching RPM Package Tittle for the NFS Server the operation fails in verification. We can use the same online update software except it points to a local Server via NFS transfer. We would also need a refresh option to refresh our client NFS exported and mounted directories as it is possible for the Update Server to be down at the time threshold for client check for updates as NO NFS drives would be available. We need to do a bit of work in Online Update Check configuration that is currently in Yast - Again we need a 'wake PC' if the time set needs to turn on a PC that is not online via APCI -- openSUSE Feature: https://features.opensuse.org/305842

Feature changed by: Scott Couston (zczc2311) Feature #305842, revision 11 Title: Provide RPM Update Server to Update All openSUSE/SLED Workstations openSUSE-11.2: New Priority Requester: Important Requested by: Scott Couston (zczc2311) Description: *Please be Patient - This is my First FATE request* Definitions in this Submission * Workstation : Any openSUSE/SLED installation that functions without direct server support * Installation Server : Any designated PC that holds a repository for the complete RPM's contained at time of software Release. * Update Server : Any designated PC that holds a repository(s) that contain online update RPM's The 'Server' would be accessible by normal NFS... et al Services currently available. Current Situation The Installation of a PC with openSUSE/SLED requires a huge number of Online Updates a situation that may never change whilst development continues. The Installation of openSUSE has the ability to perform many NFS Installations at one time whilst being able to create 1 repository server for the entire Installation RPM's for future addition of features and groups not included in the base installation. Feature Request Along the same notion of an NFS Installation I propose that we an Installation Server or Other to be an Update Server which downloads ALL RPM updates as they become available. Each Workstation then selects Online Updates from the Update Server per chosen update check cycle period. In this way each workstation needs only to connect with the Update Server rather than each workstation downloading its required updates. This has the potential to cut update traffic by the number of workstations installed on a LAN and this weighed against the traffic of downloading ALL updates and the traffic on ALL Online update Server Repositories and Mirrors external to the LAN. The concept is notedly simple however this has a huge technical repercussion and link to FATE #120340. This concept is open for addition to FATE #120340 or it can stand alone at the discretion of Novell.DE Whilst this concept is created by the author the technical impact/problems will require much input from Novell.De and Suse.DE and the author. Discussion: #1: Scott Couston (zczc2311) (2009-02-10 02:37:07) I wish the carriage returns CR held from initial text - Can be have a CR Button - Please edit initial description if required. Can we also have a preview before commit comments/initial entry #2: Scott Couston (zczc2311) (2009-02-18 05:43:26) I had envisaged that we could add another option to the Miscellaneous Section of Yast. We already have a wizard to create and install server so we can use much of the same code to create an Online Patch Update Server. Naming convention should apply to reflect Version and Architecture. Priority must also be provided and a 'wake PC' option of PC is not turned on. The very tricky bit to to set up a cron job to gather ALL Updates for the user indicated version and architecture. On the client side I would suggest we add another check box to Software Repositories to turn on and off and take regard for priority and create an NFS Client if and then browse for the update Servers name. In the absence of a matching RPM Package Tittle for the NFS Server the operation fails in verification. We can use the same online update software except it points to a local Server via NFS transfer. We would also need a refresh option to refresh our client NFS exported and mounted directories as it is possible for the Update Server to be down at the time threshold for client check for updates as NO NFS drives would be available. We need to do a bit of work in Online Update Check configuration that is currently in Yast - Again we need a 'wake PC' if the time set needs to turn on a PC that is not online via APCI #3: Andreas Jaeger (a_jaeger) (2009-06-09 14:50:43) Can't this be done with SMT - and is SMT Open Source? + #4: Scott Couston (zczc2311) (2009-09-05 20:05:21) + <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } --> + Andreas are you refering to"Simultaneous Multi-threading" If so the + following URL has information on this. + http://www.cs.washington.edu/research/smt/ + However I cannot comment on Simultaneous Multi-threading what so ever + as I am not equiped to do so - Can you elaborate ? -- openSUSE Feature: https://features.opensuse.org/305842

Feature changed by: Andreas Jaeger (a_jaeger) Feature #305842, revision 15 Title: Provide RPM Update Server to Update All openSUSE/SLED Workstations - openSUSE-11.2: New + openSUSE-11.2: Done Priority Requester: Important Info Provider: (Novell) Info Provider: (Novell) Requested by: Scott Couston (zczc2311) Description: *Please be Patient - This is my First FATE request* Definitions in this Submission * Workstation : Any openSUSE/SLED installation that functions without direct server support * Installation Server : Any designated PC that holds a repository for the complete RPM's contained at time of software Release. * Update Server : Any designated PC that holds a repository(s) that contain online update RPM's The 'Server' would be accessible by normal NFS... et al Services currently available. Current Situation The Installation of a PC with openSUSE/SLED requires a huge number of Online Updates a situation that may never change whilst development continues. The Installation of openSUSE has the ability to perform many NFS Installations at one time whilst being able to create 1 repository server for the entire Installation RPM's for future addition of features and groups not included in the base installation. Feature Request Along the same notion of an NFS Installation I propose that we an Installation Server or Other to be an Update Server which downloads ALL RPM updates as they become available. Each Workstation then selects Online Updates from the Update Server per chosen update check cycle period. In this way each workstation needs only to connect with the Update Server rather than each workstation downloading its required updates. This has the potential to cut update traffic by the number of workstations installed on a LAN and this weighed against the traffic of downloading ALL updates and the traffic on ALL Online update Server Repositories and Mirrors external to the LAN. The concept is notedly simple however this has a huge technical repercussion and link to FATE #120340. This concept is open for addition to FATE #120340 or it can stand alone at the discretion of Novell.DE Whilst this concept is created by the author the technical impact/problems will require much input from Novell.De and Suse.DE and the author. Discussion: #1: Scott Couston (zczc2311) (2009-02-10 02:37:07) I wish the carriage returns CR held from initial text - Can be have a CR Button - Please edit initial description if required. Can we also have a preview before commit comments/initial entry #2: Scott Couston (zczc2311) (2009-02-18 05:43:26) I had envisaged that we could add another option to the Miscellaneous Section of Yast. We already have a wizard to create and install server so we can use much of the same code to create an Online Patch Update Server. Naming convention should apply to reflect Version and Architecture. Priority must also be provided and a 'wake PC' option of PC is not turned on. The very tricky bit to to set up a cron job to gather ALL Updates for the user indicated version and architecture. On the client side I would suggest we add another check box to Software Repositories to turn on and off and take regard for priority and create an NFS Client if and then browse for the update Servers name. In the absence of a matching RPM Package Tittle for the NFS Server the operation fails in verification. We can use the same online update software except it points to a local Server via NFS transfer. We would also need a refresh option to refresh our client NFS exported and mounted directories as it is possible for the Update Server to be down at the time threshold for client check for updates as NO NFS drives would be available. We need to do a bit of work in Online Update Check configuration that is currently in Yast - Again we need a 'wake PC' if the time set needs to turn on a PC that is not online via APCI #3: Andreas Jaeger (a_jaeger) (2009-06-09 14:50:43) Can't this be done with SMT - and is SMT Open Source? #4: Scott Couston (zczc2311) (2009-09-05 20:05:21) <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } --> Andreas are you refering to"Simultaneous Multi-threading" If so the following URL has information on this. http://www.cs.washington.edu/research/smt/ However I cannot comment on Simultaneous Multi-threading what so ever as I am not equiped to do so - Can you elaborate ? #5: Stanislav Visnovsky (visnov) (2009-09-08 13:37:42) (reply to #4) SMT stands for Subscription Management Tool http://www.novell.com/linux/smt/. The code is open source. + #6: Andreas Jaeger (a_jaeger) (2010-03-24 13:48:36) (reply to #5) + OK, so we can mark this as done. -- openSUSE Feature: https://features.opensuse.org/305842

Feature changed by: Scott Couston (zczc2311) Feature #305842, revision 17 Title: Provide RPM Update Server to Update All openSUSE/SLED Workstations openSUSE-11.2: Done Priority Requester: Important Info Provider: (Novell) Requested by: Scott Couston (zczc2311) Product Manager: (Novell) Product Manager: (Novell) Project Manager: (Novell) Partner organization: openSUSE.org Description: *Please be Patient - This is my First FATE request* Definitions in this Submission * Workstation : Any openSUSE/SLED installation that functions without direct server support * Installation Server : Any designated PC that holds a repository for the complete RPM's contained at time of software Release. * Update Server : Any designated PC that holds a repository(s) that contain online update RPM's The 'Server' would be accessible by normal NFS... et al Services currently available. Current Situation The Installation of a PC with openSUSE/SLED requires a huge number of Online Updates a situation that may never change whilst development continues. The Installation of openSUSE has the ability to perform many NFS Installations at one time whilst being able to create 1 repository server for the entire Installation RPM's for future addition of features and groups not included in the base installation. Feature Request Along the same notion of an NFS Installation I propose that we an Installation Server or Other to be an Update Server which downloads ALL RPM updates as they become available. Each Workstation then selects Online Updates from the Update Server per chosen update check cycle period. In this way each workstation needs only to connect with the Update Server rather than each workstation downloading its required updates. This has the potential to cut update traffic by the number of workstations installed on a LAN and this weighed against the traffic of downloading ALL updates and the traffic on ALL Online update Server Repositories and Mirrors external to the LAN. The concept is notedly simple however this has a huge technical repercussion and link to FATE #120340. This concept is open for addition to FATE #120340 or it can stand alone at the discretion of Novell.DE Whilst this concept is created by the author the technical impact/problems will require much input from Novell.De and Suse.DE and the author. Discussion: #1: Scott Couston (zczc2311) (2009-02-10 02:37:07) I wish the carriage returns CR held from initial text - Can be have a CR Button - Please edit initial description if required. Can we also have a preview before commit comments/initial entry #2: Scott Couston (zczc2311) (2009-02-18 05:43:26) I had envisaged that we could add another option to the Miscellaneous Section of Yast. We already have a wizard to create and install server so we can use much of the same code to create an Online Patch Update Server. Naming convention should apply to reflect Version and Architecture. Priority must also be provided and a 'wake PC' option of PC is not turned on. The very tricky bit to to set up a cron job to gather ALL Updates for the user indicated version and architecture. On the client side I would suggest we add another check box to Software Repositories to turn on and off and take regard for priority and create an NFS Client if and then browse for the update Servers name. In the absence of a matching RPM Package Tittle for the NFS Server the operation fails in verification. We can use the same online update software except it points to a local Server via NFS transfer. We would also need a refresh option to refresh our client NFS exported and mounted directories as it is possible for the Update Server to be down at the time threshold for client check for updates as NO NFS drives would be available. We need to do a bit of work in Online Update Check configuration that is currently in Yast - Again we need a 'wake PC' if the time set needs to turn on a PC that is not online via APCI #3: Andreas Jaeger (a_jaeger) (2009-06-09 14:50:43) Can't this be done with SMT - and is SMT Open Source? #4: Scott Couston (zczc2311) (2009-09-05 20:05:21) <!-- @page { margin: 2cm } P { margin-bottom: 0.21cm } --> Andreas are you refering to"Simultaneous Multi-threading" If so the following URL has information on this. http://www.cs.washington.edu/research/smt/ However I cannot comment on Simultaneous Multi-threading what so ever as I am not equiped to do so - Can you elaborate ? #5: Stanislav Visnovsky (visnov) (2009-09-08 13:37:42) (reply to #4) SMT stands for Subscription Management Tool http://www.novell.com/linux/smt/. The code is open source. #6: Andreas Jaeger (a_jaeger) (2010-03-24 13:48:36) (reply to #5) OK, so we can mark this as done. + #7: Scott Couston (zczc2311) (2011-04-14 07:23:03) + I see the beauty of this feature fully implemented with all of its + benefits as every feature, rational, desirability has been implemented + in the most eloquent solution possible. With the Enterprise version + having this feature request named "Simplified Subscription Management + for SUSE Linux Enterprise",can we hope to see the same functionality + available to the open versions, from which this feature was born and + envisaged from....Please advise if I am just dreaming of having this + feature available to the open community...:-) -- openSUSE Feature: https://features.opensuse.org/305842