OSMC Update request! Urgent!

Since we update from one version to another of both distro and kodi, iptables get labled as altenrnative or whatever, just old.iptables should always be updated automatically, even when switching from a distro, you don’t make them for fun, they are extremely important for some people!

I updated 1 pi and 1 vero now, Tom helped me correct th errors, but i’m not updating my other 4k’s until it’s stable again. It might be a couple of lines in SSH to correct it but please do fix it for people that don’t know how.
Thank you!

@sam_nazarko this is your product, i know you stepped back, but please, help with a fix for this.

I don’t know what you’ve been advised to do, so it’s hard to comment.

Could you point me to the instructions you’ve received?

The approach to iptables is slightly different in Debian and it’s on my list to look in to this, but this is not a high priority. iptables is a complex CLI tool, and it’s expected that those who would be comfortable with the command line would also be familiar with other elements of administering a Linux system.

If it was something we shipped out of the box that was pre-configured, this would obviously be a different situation.

I haven’t stepped back from anything.

I am now aware that you messaged @Tom_Doyle for instructions and he was able to assist you.

Unfortunately I can’t fix problems that I’m not aware of, and further to this, it’s hard to ascertain the severity of issues if they are not publicly reported.

Please use forum posts here in future instead of private messages. Using private messages to troubleshoot issues deprives other users of potential solutions and inflicts a significant support burden on a single staff member. We also don’t know everything, and sometimes an additional pair of eyes, or several, can facilitate the troubleshooting process.




This isn’t private Sam it’s just in feature request (oh sorry you know me under another name, Saint may ring a bell I’ve been here since before OSMC lol).

I just triggered you because it eventually is your OS, you created it, you did very well, it’s your kid (sort of).

The best thing I can think of is while installing the new distro lifting the old rules, then replacing them in the new distro (could be a simple text command). But that’s just a suggestiion.

And yes @Tom_Doyle has been very helpful, as always, fixing the issue but this should not be a problem when updating.
I can get it to work (with a little help of the professionals like Tom) but a lot of people set this up once (or let someone set it up) and then it absolutely fails on distro update. That’s not a good thing mate!


I am aware that this isn’t a private message, but my understanding is that you’ve been seeking support via PM with @Tom_Doyle, which isn’t ideal for the reasons outlined above.

I’ve taken a look at this and can’t see what we actually need to fix. OSMC is an official Debian derivative and our intention is to follow Debian standards where possible.

iptables still works fine. It’s just no longer the default method of managing firewall rules. Managing firewall rules varies per distribution. For example, on some distributions, ufw is the method of choice.

As iptables is still supported and making it the default is very trivial (via the update-alternatives command), I’m reluctant to make further changes here and promote the use of nftables as a replacement. From what I can see on the Buster thread, users with knowledge to configure iptables have been able to re-configure it as the default trivially.

What I will need to check - I remember a conversation with @dillthedog, is that we support nftables on Vero 4K/4K+ (for 3.14 and 4.9) so that our default firewall implementation does indeed function as expected across all platforms.

Another way to look at this would be to look at how we handle SSH. As cryptography evolves, we have to update which ciphers we use. The old ciphers will still work if manually enabled, but we’d be doing people a disservice from a security perspective if we didn’t follow best practices.

Hopefully this makes things clearer


1 Like

Since it might not be ideal, there are people to go to for 1 problem and others for another.

If you think that’s ok, it’s ok. I can fix it myself with some help of @Tom_Doyle but if it’s not important for people without ANY KNOWLEDGE that buy a vero to get their hard earned (for them) iptables to the next distro because it follows basic debian protocol that’s up to you and completely your choice. That’s why this is a feature reqeust. I have 3 4k’s i’m not updating just because of this issue.
The update-alternavtives command is pretty basic in debian and comes natural for you, but even as long as I have been here, I still had to ask Tom for advice.
So maybe it’s a feature idea… you could just pull the old ones or run the alternatives command for people that can’t fix this (and for those that don’t update OSMC on multiple 4k’s just because of this issue).

(I studied cryptology, I know how SSH works but i’m no hero when it comes to iptables, I never have been, you can ask me to explain serpent,or rijndaal to you and I will most likely know more about it then you do, but implementation of the functions is a different thing, and I could never compete with you on that level).

As I said, we’ve known each other for a looooooong time (if you can recall) I’m not just bumping this for no reason, if Tom gave you the SS’s you could actually see OSMC errors out on it when updating, and asks users to mention it on the OSMC forum.


I don’t think it’s wise to do this, for the reasons outlined above. If iptables is being deprecated in distributions, there is likely good reason for it.

Do you have any proof to suggest that users have not updated because iptables is no longer the default firewall implementation on their system? By your own admission, you only discovered this post-upgrade, so this can’t even be anecdotal evidence.

OSMC can’t, and won’t, give you an error telling you to post on the forum when running a command from the CLI. We don’t have anything built-in to do to that. It can only give you this error if there is a problem when updating via My OSMC.

I made our Debian Buster test release available for a month before releasing it as stable, and only did so when we had fixed a number of issues.

Unfortunately I didn’t have any reports about the change of behaviour regarding firewalling. I suspect some users made this change with aid of a quick Google search and didn’t bother to update the testing thread with feedback.

It wouldn’t be possible to rectify things now - as the update has been out for almost a month and has been deployed to almost all of our active users.

Deploying firewall rules via the command line is complex. It is quite plausible to make mistakes that can result in a compromised system. We recommend that users rely on an external firewall or even NAT if they are IPv4 only. Our goal is to provide a mediacenter with a full fledged Linux distribution underneath, but we cannot provide a supported migration path for every change made by a user. This is the downside (for us) of making the system so configurable.

Our goal is to provide a mediacenter that requires no command line use. If you do choose to use the command line however, we expect that you are able to run some commands. If you choose to make significant changes to the system, then we expect you to adapt those changes as the system upgrades. Otherwise - where should it end? It’s possible to install a desktop environment and office suite on OSMC, but hopefully you can appreciate that this isn’t something that we would have tested when working on the Debian Buster upgrade.

I think the real long term solution is to make firewalling configurable via My OSMC’s network interface with a simple UI.

Please don’t hesitate to let us know if there’s anything that we can do for you in the future.




Of course there is, the distro gets updated and version changes but the rules stay the same.
(e.g. I now have the exact same rules on 3 boxes that I had before as well, 4 more to go).

Proof in content.

It would not be anecdtoalble evidence if it happened on one device, if it happens on multiple it starts to become something static.

Sam, come on, i’m not pulling this out of my ass. There was a literal warning in update “please post on the OSMC forum” with a 30 sec (I think) time out, then when booted into OSMC itself it prompted another message saying the same.

I can answer the rest but right now you don’t even believe your long long time customer.

This can’t happen. I wrote that code. I know what triggers that pathway. I’m really sorry, but it cannot happen from doing anything other than upgrading via My OSMC.

Debian have said that iptables is no longer the default in Buster, so it should not remain the same.

I think you need to read through what I wrote carefully. When you upgrade your devices, iptables is no longer the de-facto method of managing firewalls. This is expected, and will occur on any device you upgrade. This is not in contention. What I refer to is the fact that you are stating there are users that are refusing to upgrade because of the firewall changes, when you yourself only discovered these changes are upgrading. We have had no such reports and as of midnight, 80% of users are running the latest version of OSMC which is based on Buster.


The future of software firewalling for debian


dunno what the big deal is as Sam said this isnt a OSMC issue actually isnt an issue at all