scootstah

It's not "fake SMTP", it is a real SMTP server. It's just not designed to deliver mail to real recipients. I'm not sure what you mean by SMTP related errors. If you mean logging errors via email, then yeah it'll work for that, as long as the error handler uses the correct address/port for mailhog/mailcatcher.

Either of these: https://github.com/mailhog/MailHog http://mailcatcher.me/ Super easy to install and configure, and it provides a web interface on an alternate HTTP port for viewing mail. You can send mail to any email address and they will be captured in one big list in the web interface. I've used a couple different solutions over the years, including Postfix setups with Squirrelmail or some other web client, but this is far, far better.

OpenSUSE has a graphical installer - just follow the on-screen instructions and click next a bunch of times. You don't need to make it more complicated than it is.

Why are you zero'ing your disk to install Linux? That's really not necessary... just delete any existing partitions that you want, and create a new one. As for what partition table to use, just stick with the defaults for that stuff unless you have a reason not to.

So you're probably talking about sanitizing output to include some safe HTML, yeah? Allowing any HTML at all should really be avoided. There are better alternatives such as markdown or bbcode.

Looks fine to me.

Yes you can use SMART. That's the whole point of SMART.

You need to use SNI. Are you doing that?

No it wasn't. They're two separate things. iptables-persistent is an iptables plugin that implements netfilter-persistent.

Of course not. If your physical box or codebase is compromised then all bets are off. If your app can encrypt/decrypt, then attackers can encrypt/decrypt too (if they have access to your box). There's not really any way to get around that, except to not let attackers compromise your box. You have to take a step back and assess your realistic threat model here. What exactly are you protecting your data from? If you just want to protect data in your database and over-the-wire, then basic encryption as I've described should be sufficient. If you want to protect your server from NSA scrutiny, then no, you're in way over your head.

Does the price increase linearly with each size? Like, is 2,red == $500? And is 3,red == $750? If that's the case you can just define what each color's base price is and then multiply it by size. Otherwise you'll need to map out what each color costs for each given size.

You'd want to use a class on links that should have the confirm dialog, and then use Javascript click events to show it. See here: https://developer.mozilla.org/en-US/docs/Web/API/EventTarget/addEventListener https://developer.mozilla.org/en-US/docs/Web/Events/click

Linux distributions maintain their own packages in their own repositories. You will never have the latest version when using default repositories. When the distro maintainers decide that a package version is stable enough and fit for distribution, it will be updated in the repository. You don't need to bother trying to achieve the latest hot-off-the-press version of software on Linux. If that's what you wanted, you would probably have to compile from source at that point, and then continue doing that every single day for any new releases. Usually you can find newer major versions maintained in third-party repositories, such as for PHP7, which is very easy to install. But if you just want Apache 2.4, use whatever the distro gives you. If you just want PHP 5.6, use whatever the distro gives you.

The command should be: sudo invoke-rc.d iptables-persistent save

You could just store it in the database. But, you'll need to add the user's key to a static, secret site key in some way. If you simply use the user's key from the database to encrypt/decrypt, then the encryption is effectively useless because if there was a database breach, the attackers could just decrypt the data with the stored user key. If you add the user's key to a static site key, they would also have to compromise that key in order to decrypt.