Jump to content


Popular Content

Showing content with the highest reputation since 06/01/2009 in all areas

  1. 1 point
    Upgrading Fedora 28 Workstation to Fedora 29 Using the command line This method is the recommended and supported way to upgrade from Fedora 28to Fedora 29. Using this plugin will make your upgrade to Fedora 29 simple and easy. 1. Update software and back up your system Before you do anything, you will want to make sure you have the latest software for Fedora 28 before beginning the upgrade process. To update your software, use GNOME Software or enter the following command in a terminal. sudo dnf upgrade --refresh Additionally, make sure you back up your system before proceeding. 2. Install the DNF plugin sudo dnf install dnf-plugin-system-upgrade 3. Start the update with DNF Now that your system is up-to-date, backed up, and you have the DNF plugin installed, you can begin the upgrade by using the following command in a terminal: sudo dnf system-upgrade download --releasever=29 This command will begin downloading all of the upgrades for your machine locally to prepare for the upgrade. If you have issues when upgrading because of packages without updates, broken dependencies, or retired packages, add the ‐‐allowerasing flag when typing the above command. This will allow DNF to remove packages that may be blocking your system upgrade. 4. Reboot and upgrade Once the previous command finishes downloading all of the upgrades, your system will be ready for rebooting. To boot your system into the upgrade process, type the following command in a terminal: sudo dnf system-upgrade reboot Your system will restart after this. Many releases ago, the fedup tool would create a new option on the kernel selection / boot screen. With the dnf-plugin-system-upgrade package, your system reboots into the current kernel installed for Fedora 29; this is normal. Shortly after the kernel selection screen, your system begins the upgrade process. Now might be a good time for a coffee break! Once it finishes, your system will restart and you’ll be able to log in to your newly upgraded Fedora 29 system.
  2. 1 point
    Damn, happy birthday, mate!
  3. 1 point
    One final point in terms of security... Apache usually runs under a non-privileged account (httpd, www-data, etc - depending upon your distro) so this account needs: read access to any website content read and execute access to any website directories (execute priv = directory traversal permission) write access to any directories that it needs to amend content in (eg: caches, config dirs, upload dirs). The first two are quite easy: chmod 644 on any files and 755 on any directories and you're away. However, this also means that anyone else on the server can access website content, meaning they could be exposed to confidential information (such as database credentials, backdoor passwords, etc). Rather than set the content world-readable, two alternative options are: set the GROUP of the files/directories to match the group of the webserver account (www-data or the httpd group) then set file permissions to 640 and dirs to 750 Install suPHP on Apache, and set the content back to owner-only accessible. The first is probably a quick and dirty method of doing it, but restricts the content to read/write for owner and read-only for Apache (and nothing for anyone else), thus preventing anyone outside of the website owner and apache to access that content. The second is preferable - it makes Apache perform a "su" to the website owner, accessing it as though it owned the content. This means that all cache data and config files just need to be read/writeable by the owner - no messing about with allowing apache groups or world read-access. So why not go for that latter option all the time? There are some downsides: it requires some configuration at the Apache end, in particular a custom php.ini file per-site it requires setting file/dir permissions carefully, since suPHP will abort serving up content if the mode (owner/group/permissions) do not exactly match that in the suphp config file there is an additional processing overhead (apache needs to keep switching user prior to accessing/delivering content) which can impact busy sites. The alternative is that you set all content to 777 and not worry about it, which is what a lot of new web administrators do. And then they wonder how they got cracked, why they're serving up trojans and exploits on their websites, and how their server has become part of a spam-spewing botnet. I'm afraid "but I didn't know" isn't an adequate defence. "But I didn't research and thus permitted something easily exploitable to be let loose on the internet" is more accurate. Practise safe web administration, people. You know it makes sense!
  4. 1 point
  5. 1 point
    just type empathy in konsole then watch the konsole as you add a user in empathy same way you'd normally do it, the trick here is that any error messages will be left in the konsole...
  6. 1 point
    first one that grabs me is an ssh tunnel? god i can hear my network admin crying.... he'll hate me for telling you! due to the fact of the security issues when a SSL based transfer is made the proxy simple opens the connect and doesn't tamper with it (correctly). Needless to say this is a huge hole in the proxy, so all you do it tunnel through.. currently or net admin is out smarting the users though, basically by forcing the issue with which port the SSL transfers can be made to, this stops bt/mule etc type connections. anyway.. im sure other ways exist, but
  7. 1 point
    You could if you wanted to just install the binary issung the following command: yum install httpd
  • Create New...