Search Results

Search found 3 results on 1 pages for 'edwardteach'.

Page 1/1 | 1 

• How can I easily create cloud texture maps?

  - by EdwardTeach

  I am making 3d planets in my game; these will be viewed as "globes". Some of them will need cloud layers. I looked at various Blender tutorials for creating "earth", and for their cloud layers they use earth cloud maps from NASA. However I will be creating a fictional universe with many procedurally-generated planets. So I would like to use many variations. I'm hoping there's a way to procedurally generate cloud maps such as the NASA link. I will also need to create gas giants, so I will also need other kinds of cloud texture maps. If that is too difficult, I could fall back to creating several variations of cloud maps. For example, 3 for earth-like, 3 for gas giants, etc. So how do I statically create or programmatically generate such cloud maps?

  Read the article

• on Red Hat Enterprise and CentOS, what is creating /var/run/reboot-required?

  - by EdwardTeach

  On CentOS 5.8+ and Red Hat Enterprise 6+, when installing/updating packages, I notice a flag file /var/run/reboot-required is created when appropriate. On Ubuntu (and Debian too, I'm guessing), if package "update-notifier-common" is installed, a package postinst script triggers creation of this flag file. On RHEL/CentOS I can't figure out how this is happening. For instance, on RHEL and CentOS I recently installed several updates and /var/run/reboot-required was created. One of them was an "openssl" package upgrade. I assume this was what created the flag file, since on Ubuntu it also works this way. However I looked at all "rpm -q --scripts" for each updated package, and didn't see anything that was likely to have created that flag file. Mostly I saw "postinstall program: /sbin/ldconfig". So my questions are: What creates this flag file on RHEL/CentOS? Does it require a special package to be installed, analogous to the "update-notifier-common" package on Ubuntu?

  Read the article

• postfix smtp_fallback_relay for deferred messages to a single domain

  - by EdwardTeach

  I use Postfix to send messages to a mail server outside my organization which frequently rejects/defers my mail. My Postfix server sees that these messages are deferred and tries again, eventually getting through. Final delivery can take up to an hour, which makes my users unhappy. In comparison, mail from my Postfix server to other hosts works normally. I have now found out about a second, unofficial MX for this domain that does not reject/defer mail. This second MX does not appear when doing a DNS MX query for the domain. Therefore, for the problem domain I would like to use this second MX as a fallback. That is: whenever mail is deferred by the primary MX, try again on the unofficial second MX. I see that there is already a postfix configuration "smtp_fallback_relay". However the documentation seems to indicate that I can not restrict usage of the fallback to a single domain. The documentation also doesn't mention deferred message handling. So is there a way to configure a single-domain, deferred-retry fallback host in Postfix? For reference, I am including my postconf output (the host names and ip addresses are fake): alias_database = hash:/etc/aliases alias_maps = hash:/etc/aliases, hash:/etc/postfix/legacy_mailman, ldap:/etc/postfix/ldap-aliases.cf append_dot_mydomain = no biff = no config_directory = /etc/postfix default_destination_concurrency_limit = 2 inet_interfaces = all inet_protocols = all local_destination_concurrency_limit = 2 local_recipient_maps = $alias_maps mailbox_size_limit = 0 mydestination = myhost.my.network, localhost.my.network, localhost, my.network myhostname = myhost.my.network mynetworks = 127.0.0.0/8, [::ffff:127.0.0.0]/104, [::1]/128, 10.10.10.0/24 myorigin = my.network readme_directory = no recipient_delimiter = + relay_domains = $mydestination relayhost = smtp_fallback_relay = the.problem.host smtp_header_checks = smtpd_banner = $myhostname ESMTP $mail_name virtual_alias_maps = hash:/etc/postfix/virtual

  Read the article

1