Koozali.org: home of the SME Server
Contribs.org Forums => Koozali SME Server 10.x => Topic started by: jameswilson on February 19, 2021, 01:35:11 PM
-
I have left the machine in the following state incase any further info is needed
-
Well, a number of Proxmox VM installs with latest iso, raid1 and single disk..yet to see that error and all have been successful unless doing odd things with manual partitioning
So cant help, others may have a clue
-
When you say Yum update to beta 1, do you mean you have a Alpha 5 install that you are attempting to update to Beta 1 status .. it can be done, a simple yum update doesn't do it..
-
Yes thats exactly what i was doing.
Sorry then how do you move between versions then if not by doing a yum update?
-
have you tried to enable ipv6 on this vm ?
what returns ipconfig ?
-
I haven't but can. However my local gateway is a sme9
-
I haven't but can. However my local gateway is a sme9
Nothing to do with v9.
And the very last line shows something somewhere somehow has enabled or is trying to connect over IPv6.
IO::Socket::INET6 Connect: connection refused at /sbin/e-smith/ldif-fix line 402
IPv6 should not be enabled as it is not currently supported.
So the question is what.
Show ipconfig or ip addr show
-
Also note that Alpha 5 was testing only, and there is no guaranteed upgrade path to Beta, and hence YMMV.
As per the release notes there were HUGE underlying changes which may break stuff. Hence Alpha status.
Beta should see less breaking changes and enable a backup v9/restore to v10 path, and likely upgrade to RC/Release status.
-
Fair enough
Should i reboot it as its just at the screen as posted above?
-
Need to find out where you are at - a reboot might be messy. Is this just a trst machine?
You have got a backup haven't you?
Have you got ssh shell access?
Please describe fully how you got to this point.
Please also answer questions previously asked
-
no no its just a test machine. Im just reporting things I find.
Trying to do my bit, im not looking at migrating anything yet!! ;-)
Ive pressed ctrl-c and got this
-
ip details
-
Please describe fully how you got to this point.
Please also answer questions previously asked
just ran 'yum update' enabled the smecontribs repo
Got the first error as per the screenshot about connection refused. Then it just stayed like that.
Pressed Enter got a new line
pressed ctrl c, got the error as per 2nd screenshot
Havnt done a reboot or reconfigure yet.
As above test machine on proxmox. Was an sme10-alpha
Just trying to help with the testing
-
ip details
I don't see the details we asked for....
Please go back and write down exactly what you did to get to this point and tell us.
Without that level of detail this is all pretty meaningless.
So, server version, where you were with updates, what other rpms/contribs you had tried to install, what you did to trigger this, the output the address commands above etc.
You titled this as "Yum update to beta 1 failed" but what stage were you at before this? Fully updated, part updated, not updated? What command did you use to update?
All we really have so far is 'the car won't start' !!
And I know that you have been playing because "ldif-fix" is not in a stock install....... so how did it get there?
My guess is you have been trying all sorts of things out - possibly some v9 contribs - and then tried to upgrade, and something broke.
So my gut instinct this is a won't fix because this is not a normal install.
just ran 'yum update' enabled the smecontribs repo
Ahhhhh. Do you think that is a sensible move? You should never just do 'update' with extra repos enabled.
And I am not sure that is the issue as there is almost nothing in the SME v10 contribs repo that would really do that:
http://mirror.canada.pialasse.com/releases/testing/10.0.beta1/smecontribs/x86_64/RPMS/
So, that isn't the whole story..............
I suspect you enabled other repos when you did update eg smedev???? In which case your VM is toast.
-
Note - Terry has seen this too.
We are looking at it.
-
FWIW
yum provides /sbin/e-smith/ldif-fix
e-smith-ldap-5.6.0-9.el7.sme.noarch : e-smith server and gateway - LDAP module
Repo : smeos
Matched from:
Filename : /sbin/e-smith/ldif-fix
-
no no its just a test machine. Im just reporting things I find.
Trying to do my bit, im not looking at migrating anything yet!! ;-)
Ive pressed ctrl-c and got this
Please keep at it, all goes to the knowledgebase
OK, managed to reproduce by doing a straight yum update to a new A5 install - why? :-) just to know :-) if you install an A5 iso and then update it by updating some packages before others you dont get the error, that was how we did it during testing, building on fixes..the error is related to a bug fix to e-smith-ldap.
So if you do a straight yum update now to a Alpha base install, make no sense now by the way, packages are installed and end up with an almost cart before the horse scenario, lesson, Alphas are for testing only and to validate a fix, they are not designed to be updated to the finished product :-) stay with it, you and we have gained some knowledge...
Added: also if the update is done after some other updates and not before them you can also produce the error
-
My last words :-)
This is the same as a point in validating bug fixes in Dec 2020 you had to update smeserver-yum, e-smith-base and smeserver-php before any other updates otherwise the alpha crashed when you did a general update
-
And hence the reason to keep lots of notes when testing. They are vital for diagnosis.
Without them we're left guessing at best.
-
Agreed I want to help
Previous posts put me off because I'm not doing it right for you. I'll try harder. I know your all up against it and I really appreciate what your doing.
I'll look at the vm regarding things I shouldn't of installed. It was a test vm purely for affa. I've used it to update from sme 7 beta 6 when I first arrived here.
To be clear this vm was alpha 5 using the info on the forum to install affa. That was all.
I want to test and help but it appears I'm making things worse, sorry
-
Agreed I want to help
and you are, bottom line, you are. so hang in there.
-
Indeed.
You only get better with practice. We've all been there.
Personally I always:
Keep a notepad open to write a list of commands & notes as I go. "Repeatability' is vital.
Setup remote ssh immediately so it is easier to copy & paste from logs etc. Screen shots are a pain as we have to type out the error again.
Help us by doing some of that leg work!!
If we ask for information please give it.
Talk to us on Rocket (you have an account) and we can guide you a bit. We don't bite :lol:
-
I know you don't, it does look that way though on here. Maybe I should of gone into more detail about test machine etc. Too late now for that.
I get your point about wasting time on non issues, however you also ask for help with testing. I cant do what you guys do but I'd suggest not being too critical when someone like me tries to help, I'm sure there are loads of us like that even I thought I'm no use on this. I may as well not bother.
The test machine is a vm and no issue to kill it, I'm looking to test affa and letsencrypt and move a couple of non essential things over. Imo you can't test properly till it's active. I'm willing to do that. Yes they are 'production' sites but favours and free stuff so downtime isn't an issue. I just want to help get sme10 there. As a side note I started with 7b6 that I had in production. That ran my current business as a start up. I Haven't looked back!
-
Setup remote ssh immediately so it is easier to copy & paste from logs etc. Screen shots are a pain as we have to type out the error again.
This, over the journey have found this to be the first thing to do after installing, vital, always, keep a copy of the commands needed in a text file on my desktop, apart from being able via server-manager
# db configuration setprop sshd status enabled
# db configuration setprop sshd PermitRootLogin yes
# db configuration setprop sshd acccess private
# db configuration setprop sshd PasswordAuthentication yes
# /sbin/e-smith/signal-event remoteaccess-update
-
I just read my post back, I do mean it in a posative light, don't read it in a negative one.
-
This, over the journey have found this to be the first thing to do after installing, vital, always, keep a copy of the commands needed in a text file on my desktop, apart from being able via server-manager
# db configuration setprop sshd status enabled
# db configuration setprop sshd PermitRootLogin yes
# db configuration setprop sshd acccess private
# db configuration setprop sshd PasswordAuthentication yes
# /sbin/e-smith/signal-event remoteaccess-update
Yes I do that but via the https admin page. However they are useful commands going forward
-
I just read my post back, I do mean it in a posative light, don't read it in a negative one.
Hehe.... We know.
Just trying to help you learn so you can help both us and yourself more.
-
Cool as long as you know ;-)
-
This, over the journey have found this to be the first thing to do after installing, vital, always, keep a copy of the commands needed in a text file on my desktop, apart from being able via server-manager
# db configuration setprop sshd status enabled
# db configuration setprop sshd PermitRootLogin yes
# db configuration setprop sshd acccess private
# db configuration setprop sshd PasswordAuthentication yes
# /sbin/e-smith/signal-event remoteaccess-update
Note: access with 2 x c
# db configuration setprop sshd access private
-
Note: access with 2 x c
# db configuration setprop sshd access private
Its the Australian spelling, should have show the New Zealand one.. :-)