You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have a large cluster (>800 nodes) that still use a RHEL6 based distribution (yeah, it's old). I have been trying to set up luna for the last week to get rid of the old deploy software (which is very slow and unreliable) and now it works. These notes are just in case my work is useful for other people (or just for posterity). I had make the following changes:
luna/osimage.py
The dracut (from dracut-004-388 rpm) syntax is different, for example it doesn't know the --kver option. Instead, the kernel version is the last argument: # dracut_cmd = (['/usr/sbin/dracut', '--force', '--kver', kernver] + # modules_add + modules_remove + drivers_add + # drivers_remove + [tmp_path + '/' + initrdfile]) dracut_cmd = (['/usr/sbin/dracut', '--force'] + ['--add', " ".join(modules_add) ] + ['--omit', " ".join(modules_remove)] +drivers_add + drivers_remove + [tmp_path + '/' + initrdfile] + [kernver])
Also had to tweak the argument to --add and --omit there a bit.
I do not know how stable the dracut syntax is, maybe it would be an idea to define a template of this in the database, so this was changeable without touching the code.
Since this dracut is so old, I also had to create "check" and "install" files from the contrib/dracut/95luna/module-setup.sh file, but this is straightforward.
Compatibility symlinks:
In the scripts luna-start.sh and templ_install.sh, external programs are called with full path, i.e.: luna-start:109: /usr/bin/ps ...
Since ps is in /bin/ on this old Linux, I created a symlink. Also for tar and dracut.
Personally, I prefer to set the PATH at the start of the script properly and then use command -p to save the full path in a variable. Then I can also check if this executable is actually present.
contrib/dracut/95luna/luna-start.sh and templates/templ_install.cfg:
At first, dracut only installed dash, not bash, into the initrd. dash wouldn't understand the function definitions, e.g., luna-start.sh:25: function are_macs_equal () {
It did not understand the "function" keyword and I think it also didn't like the space between the function name and the (empty) argument parentheses.
For compatibility, I think omitting the "function" and deleting the whitespace would be a good idea. By the way, the functions in templ_install.cfg don't have parentheses: templ_install.cfg:6: function update_status {
Maybe it would also be a good idea to use /bin/bash instead of /bin/sh in luna-start.sh when calling the install script: luna-start.sh:162: /bin/sh /luna/install.sh && RES="success"
since bash is also used explicitly in other places, e.g. in the shebang of luna-start.sh (and also in the shebang of templ_install.cfg, but this is obviously not used when running the install script)
Compiling a recent rb_libtorrent (1.0.9) with the old gcc 4.4.7 was also not directly successful, but it worked eventually. Considerably older version did not work well together with ltorrent (performance was very low).
Lastly, I build these images on a Centos 7 node, which is means yum and rpm are much more recent, so I have to rebuild the RPM db (rm -f /var/lib/rpm/Name && rpm --rebuilddb) once a node is installed or the old rpm will not be able to read the db.
One feature I added was to have the option to change the localboot parameter in the same way the status is updated using curl. Our nodes are set to boot from the network first. To deploy, localboot must be off, but not every reboot should be a deploy. I put one function in node.py (update_localboot) and a branch in get() in manager.py which sets localboot to 'yes'. This is triggered from a function update_localboot (which calls curl) in templ_install.cfg, which is called from the postscript script after the boot loader is installed: curl -s [...]/luna?step=configure&node={{ p['name'] }}&localboot=$1
But maybe this is superseded by the REST API being developed?
I don't expect any changes to your upstream for such an old system (which is hopefully scrapped next year). But if any of the above sound like they a good idea, I'll be happy to send a patch.
The text was updated successfully, but these errors were encountered:
We have a large cluster (>800 nodes) that still use a RHEL6 based distribution (yeah, it's old). I have been trying to set up luna for the last week to get rid of the old deploy software (which is very slow and unreliable) and now it works. These notes are just in case my work is useful for other people (or just for posterity). I had make the following changes:
The dracut (from dracut-004-388 rpm) syntax is different, for example it doesn't know the --kver option. Instead, the kernel version is the last argument:
# dracut_cmd = (['/usr/sbin/dracut', '--force', '--kver', kernver] +
# modules_add + modules_remove + drivers_add +
# drivers_remove + [tmp_path + '/' + initrdfile])
dracut_cmd = (['/usr/sbin/dracut', '--force'] +
['--add', " ".join(modules_add) ] + ['--omit', " ".join(modules_remove)] +
drivers_add + drivers_remove + [tmp_path + '/' + initrdfile] + [kernver])
Also had to tweak the argument to --add and --omit there a bit.
I do not know how stable the dracut syntax is, maybe it would be an idea to define a template of this in the database, so this was changeable without touching the code.
Since this dracut is so old, I also had to create "check" and "install" files from the contrib/dracut/95luna/module-setup.sh file, but this is straightforward.
Compatibility symlinks:
In the scripts luna-start.sh and templ_install.sh, external programs are called with full path, i.e.:
luna-start:109: /usr/bin/ps ...
Since ps is in /bin/ on this old Linux, I created a symlink. Also for tar and dracut.
Personally, I prefer to set the PATH at the start of the script properly and then use command -p to save the full path in a variable. Then I can also check if this executable is actually present.
contrib/dracut/95luna/luna-start.sh and templates/templ_install.cfg:
At first, dracut only installed dash, not bash, into the initrd. dash wouldn't understand the function definitions, e.g.,
luna-start.sh:25: function are_macs_equal () {
It did not understand the "function" keyword and I think it also didn't like the space between the function name and the (empty) argument parentheses.
For compatibility, I think omitting the "function" and deleting the whitespace would be a good idea. By the way, the functions in templ_install.cfg don't have parentheses:
templ_install.cfg:6: function update_status {
Maybe it would also be a good idea to use
/bin/bash
instead of/bin/sh
in luna-start.sh when calling the install script:luna-start.sh:162: /bin/sh /luna/install.sh && RES="success"
since
bash
is also used explicitly in other places, e.g. in the shebang of luna-start.sh (and also in the shebang of templ_install.cfg, but this is obviously not used when running the install script)Compiling a recent rb_libtorrent (1.0.9) with the old gcc 4.4.7 was also not directly successful, but it worked eventually. Considerably older version did not work well together with ltorrent (performance was very low).
Lastly, I build these images on a Centos 7 node, which is means yum and rpm are much more recent, so I have to rebuild the RPM db (
rm -f /var/lib/rpm/Name && rpm --rebuilddb
) once a node is installed or the old rpm will not be able to read the db.One feature I added was to have the option to change the localboot parameter in the same way the status is updated using curl. Our nodes are set to boot from the network first. To deploy, localboot must be off, but not every reboot should be a deploy. I put one function in node.py (update_localboot) and a branch in get() in manager.py which sets localboot to 'yes'. This is triggered from a function update_localboot (which calls curl) in templ_install.cfg, which is called from the postscript script after the boot loader is installed:
curl -s [...]/luna?step=configure&node={{ p['name'] }}&localboot=$1
But maybe this is superseded by the REST API being developed?
I don't expect any changes to your upstream for such an old system (which is hopefully scrapped next year). But if any of the above sound like they a good idea, I'll be happy to send a patch.
The text was updated successfully, but these errors were encountered: