• Our team is looking to connect with folks who use email services provided by Plesk, or a premium service. If you'd like to be part of the discovery process and share your experiences, we invite you to complete this short screening survey. If your responses match the persona we are looking for, you'll receive a link to schedule a call at your convenience. We look forward to hearing from you!
  • The BIND DNS server has already been deprecated and removed from Plesk for Windows.
    If a Plesk for Windows server is still using BIND, the upgrade to Plesk Obsidian 18.0.70 will be unavailable until the administrator switches the DNS server to Microsoft DNS. We strongly recommend transitioning to Microsoft DNS within the next 6 weeks, before the Plesk 18.0.70 release.
  • The Horde component is removed from Plesk Installer. We recommend switching to another webmail software supported in Plesk.

partitioning suggestions

D

dvdpa

Guest
Hi

I want to migrate to a new box with more drive space and in the process upgrade the os from redhat 3es to redhat 4es.

I have 145gb raid 1 and am looking for advice on how to best
partition the drive.

Thanks

Chuck
 
first partition, /boot, I keep this around 256-512MB. This is to ensure that the partition is on the first 1024 cylinders of the disk. Some older bioses cant handle booting if you're over that. The secret here is that it also lets you build raid mirrors AFTER the partitions have been set up.

Second partition, swap, I go with between x1 and x2 the amount of ram.

Last partition /, all remaining space goes there.
 
Thanks for the info, I set myself short when I partitioned my server the first time, your partitioning will avoid that problem.

What is the best way to move the sites to a new plesk setup?

Use the backup manager and backup each client then restore to
new machine? The new server will not have the same IPs is
there something I will need to edit?

I have 8.1.0 running mysql5 php5 rhat es 3 going to plesk 8.1.1
rhat es 4.

Thanks

Chuck
 
If you've got 2 servers, you can use the migration manager to do it. Thats generally the safest path, allowing you some testing time before you go live with the new system.
 
One more question on the partitioning, should tmp be a folder or a partion in the / space?

Thanks

Chuck
 
Some people set up a separate /tmp directory so they can flip the noexec bit on it. Ostensibly thats to keep the badguys from uploading scripts to /tmp and running them through the web server. It doesnt actually work though, since they just call the script directly (sh /tmp/somebadguyscript).
 
then I will just leave it as a folder.

I will be using redhat 4 es since version 5 is not yet supported.
I plan to get the ASL on this server, should I install selinux
on the inital install and the firewall?

Thanks

Chuck
 
Yes, absolutely. As painful as SELinux is to configure, it really is a very powerful security system. It is as far as I know, the only actively developed trusted operating system on the market.

That being said it is a mind-numbing excercise in some really escoteric security concepts. It's rooted in the world of data labeling and and role-based security used by intelligence agencies. Because of that, its existing security policies are built around labeling data, and controlling how it can move around in the operating system, rather than providing practical security controls for a web application hosting environment like Plesk. Its not that doesn't have that capability, its just that noone has had the time or motivation to really do it yet.
 
Originally posted by atomicturtle
Some people set up a separate /tmp directory so they can flip the noexec bit on it. Ostensibly thats to keep the badguys from uploading scripts to /tmp and running them through the web server. It doesnt actually work though, since they just call the script directly (sh /tmp/somebadguyscript).

Atomic, is there any other way to secure the /tmp folder if partitioning with a noexec nosuid restrictions dosent really work.
 
grsecurity has probably the most painless implementation, using Trusted Path Execution. Basically that means that an untrusted user (apache, or whoever) can only run things owned by root. The effect is the whole file system is like "noexec", for users that you stick in the "untrusted" group. It should be possible to get the same effect with SELinux, not that I've tried this, but by saying something along the lines of apache cant execute things in directories labeled tmpfs_t. Or maybe flip that around, and create a policy around apache that says what labels it can execute (unless allow, deny). One of the nice things about not having suPHP in the mix here is it simplifies making rules like this. Not that I think suphp is a bad idea, its just making security security policies around a single UID (apache) is a lot less time effort.
 
Back
Top